Ny NTNU-forskning: Fire steder skoen trykker for smidige team

Torgeir Dingsøyr, professor i programvareutvikling («software engineering») ved NTNU, har sammen med kolleger brukt ti år på å se på hva som fungerer best for de menneskelige relasjonene i et team som jobber smidig. Hva viser forskning, og hva viser praksis?

Resultatet av studien er en helt ny modell for hvordan teamarbeid skal gå knirkefritt for smidige team.

– Hva kan man gjøre i et team for å jobbe bedre sammen? Vi tenker at teamarbeid er så viktig i programvareutvikling. Det finnes et estimat på at det snart er 30 millioner utviklere i verden. De fleste jobber i team og med smidige metoder, sier Dingsøyr.

Det finnes en stor mengde modeller for smidige metoder, men det er lite i arbeidsformene som er forskningsbasert, og det ville NTNU-teamet gjøre noe med.

– Det er mange amerikanske guruer som har foreslått metoder. Det er mye bra i de rådene, det er oppegående folk. Men dette er et felt som er såpass viktig at det bør være basert på forskningsbaserte råd, sier Dingsøyr.

Sammen med Yngve Lindsjørn ved Universitetet i Oslo og Diane Strode ved Whitireia Polytechnic i New Zealand har målet vært å finne ut hva som kjennetegner effektivt teamarbeid i smidig programvareutvikling.

Diane Strode har fulgt casestudier på New Zealand. Dingsøyr og Lindsjørn har spurt og undersøkt team i Norge for å finne ut hva som fremmer og hemmer teamarbeidet.

Fire steder skoen trykker

De vanligste problemene Dingsøyr vil trekke fram etter å ha gått gjennom både litteratur og metoder som er laget ut fra praksis, er:

• Problemer med team-tankegang og å sette teamet sine mål først.
• Uvant å jobbe uten leder.
• Lite overlapping mellom teammedlemmenes kunnskapsområder.
• Tilpasningsevne og å utnytte potensial for forbedring.

Modellen er tilpasset team som sitter fysisk sammen. At koronaen kom, gjør ikke faktorene mindre relevante, mener Dingsøyr.

Team som samarbeider digitalt må gjøre tilpasninger, til tross for at verktøyene for samarbeid har blitt bedre.

1. Problemer med teamorientering

Mange eksisterende studier peker på utfordringer med det Dingsøyr og kollegene kaller teamorientering. Det handler om å sette teamets beste før sitt eget.

– Ofte, hvis du har en liste med arbeidsoppgaver, er det en tendens til at noen velger noe du kan fra før, eller noe de har lyst til å lære, fremfor noe som er viktig for teamet som helhet, sier Dingsøyr.

Oppgavene som er viktige for oppdragsgiver eller kunde blir lavere prioritert.

2. Savner en sjef

I smidig metodikk er teamene selvstyrte. Det er opp til teamet å bestemme hvem som er mest egnet for oppgaven og når den bør gjøres. Men mange er vant til å ha en leder som tar den eksterne kommunikasjonen og kanskje deler ut oppgaver.

– Det er en utfordring å bli vant til å jobbe uten leder, men der det er kunnskapsarbeidere blir det suboptimalt hvis en leder uten tekniske bakgrunn tar beslutninger, sier Dingsøyr.

3. For lite overlappende kunnskap

Overlappende kunnskap er ofte kalt redundans i forskningen. Det blir ofte prioritert bort, fordi det er dyrt å ha flere som kjenner til det samme området.

– Hvis det bare er én person som kan området som er viktig for kunden, da er det risiko for at den personen blir veldig opptatt, mens det blir mindre på de andre, sier Dingsøyr.

Han mener det er flere løsninger på det, og at parprogrammering er en av dem. Det at to personer sitter sammen og koder, fører til færre feil og mindre tid på å sikre kvalitet i kodegjennomgang. I kodegjennomgang må man ofte vente på innspill fra kolleger, som kan føre til at du må sette deg inn igjen i ting du jobbet med for dager eller uker siden. Parprogrammering er en nyttig praksis for å sikre redundans, spesielt for personer med liten erfaring, blant annet vist i studier fra norske Simula.

– I praksis tror jeg mange smidige team tester ut selv og finner ut om det fungerer eller ikke. Det er en kostnad ved å parprogrammere, eller lære opp nye på andre måter, så det kan være at man tror det ikke er effektivt. Jeg vil tenke at det oftere er mer effektivt enn man tror, så lenge det er kunnskap man trenger en viss tid fremover i teamet, sier Dingsøyr.

4. Tilpasningsevne og potensial for forbedring

Forskerne fant at det ofte er lav bevissthet rundt viktigheten av å tilpasse teamarbeidet til endringer, enten det er internt i teamet eller skyldes noe utenfra.

– Det er kanskje fordi man tenker at det er håndtert i smidigmetoder, mener Dingsøyr.

I Scrum-metoden, for eksempel, der et retrospektiv-møte blir gjennomført hver andre eller tredje uke. Her bør folk legge litt mer av sjela si i det, mener Dingsøyr.

– Vi ser at en del kjører gjennom møtene veldig fort. De har en rask brainstorm og noterer noen punkter. Ofte er det en rask løsning på et problem, istedenfor at man gjør en dypere årsaksanalyse og finner årsaken til problemet. Praksisen er der, men man får ikke ut det fulle potensialet.

Laget ny modell

Forfatterne egen modell har de døpt Agile Teamwork Effectiveness Model. Den har fem teamarbeidskomponenter:

• Delt ledelse.
• Tilbakemelding fra kolleger.
• Overlappende kunnskapsfelt, eller redundans.
• Tilpasningsevne.
• Teamorientering.

– Når man lager en sånn modell, er det en forenkling av virkeligheten. Det er veldig fint å ha sånne modeller av virkeligheten som forenkler det til det som er viktigst, sier Dingsøyr.

NTNU-modellen for smidige team er fagfellevurdert og publisert i journalen Empirical Software Engineering. Den er også publisert i bransjemagasinet Amplify (via nettstedet Cutter.com) der den er beskrevet for smidige team som eventuelt vil sette det ut i praksis.

Modellen er delvis basert på fokusgruppestudier i IT-bransjen i Norge, og mye av arbeidet med studien er finansiert av Norges forskningsråd og norske bedrifter.