33 tips til selvorganiserende programvareteam

Innenfor programvareindustrien er “selvorganiserende team” en trend i tiden. Målet er hypereffektive team som skaper de beste løsningene. Og det er mange veier man kan gå for å komme dit. På mitt team har vi jobbet mot dette målet de siste 3 årene og finner stadig noe vi kan forbedre. Her er noen tips for å komme i gang. NB! Hver og en av tipsene er like viktige!

  1. Sett sammen teamet av personer med utfyllende evner og interesser

  2. Innfør en arbeidsflyt der medlemmene på teamet har mulighet til å plukke arbeidsoppgaver etter lyst, interesse og faglig styrke

  3. Skap en felles ansvarsfølelse, stol på hverandre, hjelp hverandre
    De tre første punktene virker som en selvfølge, men det er ikke alltid dette blir vektlagt. Gjør noe med det!

  4. Anskaff et wiki-lignende verktøy
    Dere kommer til å få bruk for det.

  5. Bytt på å gjøre en del arbeidsoppgaver
    Slik får man utvekslet kompetanse og redusert sårbarhet med tanke på “nøkkelpersoner”.

  6. Evaluer forrige arbeidsperiode
    Hvis et team skal finne ut hvordan det ønsker å jobbe må det identifisere hvor skoen trykker. Det kan for eksempel gjøres på denne måten:
     - hver og en på teamet forteller hva som var positivt og negativt med forrige arbeidsperiode. NB! Ingen avbrytelser eller diskusjoner her.
     - grupper negative områder
     - diskuter negative områder og finn tiltak til neste arbeidsperiode

  7. Kommuniser med produkteier og brukere

  8. IKKE kommuniser med produkteier/brukere ved hjelp av e-post
    Det er INGEN fordeler ved å kommunisere ved hjelp av e-post:
     - ingen andre enn de som får e-posten vet hva som kommuniseres
     - diskusjoner er bortimot umulig å strukturere ved hjelp av e-post, slik at man kan i ettertid kan forstå innholdet
     - nye medlemmer på teamet får ikke innblikk i viktig historikk

  9. Gjerne kommuniser med produkteier ved hjelp av et wiki-lignende verktøy

  10. Innfør en fast puls i arbeidet
    “Fast puls” betyr regelmessig å gjennomføre en del faste aktiviteter:
     - avklaring av spørsmål og hindringer med produkteier
     - evaluering av forrige arbeidsperiode
     - demo av programvare som er utviklet
     - levering av programvare

  11. Noter ned alle hindringer og spørsmål i det daglige arbeidet, ta det opp på neste avklaringsmøte med produkteier

  12. IKKE la enkelthindringer stoppe flyten, det meste kan vente litt, se forrige punkt.

  13. Gjerne noter hindringer og spørsmål i et wiki-lignende verktøy

  14. Evaluer forrige arbeidsperiode. Start med å gå gjennom hvilke tiltak man satte opp forrige gang

  15. Vær villig til å gjøre endringer
    Dette punktet virker som en selvfølge, men er basis for at teamet sammen finner fram til en god arbeidsform. Konservative teammedlemmer kan være et hinder for å gjøre forbedringer, og det er derfor viktig å være (selv)bevisst rundt dette punktet.

  16. Ha det moro

  17. Møt virkelige brukere og lytt på hva de plages med, gjerne sammen med produkteier

  18. La minst 2-3 personer på teamet finne ut hva brukerne har behov for og hvordan systemet kan løse behovene
    Husk! Det er ikke alltid at: Hva brukerne plages med = hva brukerne har behov for -> krav. Det er best å være flere personer med forskjellig bakgrunn sammen når man skal analysere dette, for å få belyst forskjellige perspektiver.

  19. Spesifiser krav

  20. IKKE spesifiser krav i dokumenter

  21. Få produkteier til å eksplisitt godkjenne alle krav etter at teamet har bearbeidet dem

  22. Gjerne samle alle krav i et wiki-lignende verktøy

  23. Oppdater krav underveis, hver gang dere tror dere har forstått brukernes behov eller dere støter på en teknisk hindring som gjør at løsningen blir annerledes enn først planlagt. NB! Husk punkt 21!
    Å spesifisere krav i dokumenter er like uhensiktsmessig som å kommunisere med produkteier på e-post. Spørsmålet “Hva er gjeldende krav?” dukker alltid opp, og det er ingen gode svar, bare upålitelige forslag: "Dokumentet som ligger på filtjener ‘X’ har kanskje siste krav", eller “Jeg mener jeg sendte ut oppdatert kravdokument på e-post i forrige uke”.
    Når produkteier må ta stilling til hvert enkelt krav ved å godkjenne dem i et wiki-lignende verktøy tvinger man frem en produktiv diskusjon som er synlig for alle involverte parter.

  24. Vær tålmodig
    Endring tar tid. Selvorganisering er endring.

  25. Automatiser kjedelige oppgaver
    Kjedelige oppgaver er en risikofaktor! Når man gjør kjedelige oppgaver er det stor sannsynlighet for at man begår feil. Siden kjedelige oppgaver også ofte er tidkrevende vil en nyttig bieffekt av å automatisere være at man øker effektiviteten.

  26. Skriv kode sammen

  27. Skriv og diskuter gjerne kode sammen med “testere"

  28. Skap en kultur der alle på teamet gjør kvalitetssikring så tidlig som mulig, det lønner seg
    Koding og testing er to sider av samme sak. Målet er å skape programvare som gjør det den skal gjøre og ikke noe annet (det vil si “bugs”). Derfor bør alle på teamet gjøre begge deler. Og gjerne sammen, da det er lettere å lage riktig kode på et tidlig stadium når man er nødt til å diskutere den. Å lage riktig kode er egentlig er å finne “bugs”, før de er laget!

  29. Lever programvare så ofte som mulig slik at teamet får tilbakemelding på utført arbeid så fort som mulig slik at teamet kan forbedre seg kontinuerlig

  30. Si “NEI” til oppgaver teamet ikke har lyst til å jobbe med eller ikke føler det har forutsetninger for å løse

  31. Evaluer forrige arbeidsperiode. NB! Dette er det viktigste tipset!

  32. Skaff en kunde som skjønner at det er lurt å jobbe på denne måten - eller omvend en kunde som ikke har skjønt det enda

  33. Følg disse tipsene og få et team av dyktige personer som ønsker å jobbe sammen over lengre tid

Litt om forfatteren

HåvardKB

Håvard Kvam Buvik

Håvard har jobbet i Kantega siden 2003 og er opptatt av mange aspekter ved programvareutvikling: Fra kravhåndtering og gode løsninger til effektiv arbeidsmetodikk og koding.
comments powered by Disqus