Tor Erlend Fægri Tor.E.Fegri@sintef.no SINTEF IKT Utvikling av breddekunnskap er viktig for effektivt teamarbeid men krever aktiv ledelse Tor Erlend Fægri Tor.E.Fegri@sintef.no SINTEF IKT

Breddekunnskap i systemutvikling Teamarbeid er viktig i smidig systemutvikling Effektivt teamarbeid krever at team medlemmer har felles ”språk”, felles begreper, felles forståelse av problemer. Dette er en type nødvendig redundans (Salas et al. 2005) Kreativitet er også en viktig side ved systemutvikling: Innovasjon, problemløsning krever nye ideer. En “bredde” i kunnskapen – det vil si kobling av kunnskap fra flere spesialiteter – er ofte utgangspunkt for innovasjon (Taylor and Greve 2006, Vera and Crossan 2005). E. Salas, D.E. Sims and C.S. Burke (2005). “Is there a "big five" in teamwork?,” Small Group Research 36(5): 555-599. A. Taylor and H.R. Greve (2006). “Superman or the fantastic four? Knowledge combination and experience in innovative teams,” Academy of Management Journal 49(4): 723-740. D. Vera and M. Crossan (2005). “Improvisation and innovative performance in teams,” Organization Science 16(3): 203-224.

Bredde- kunnskap Bredde- kunnskap Redundant (overlappende) kunnskap

Spesialisering: En trussel Spesialisering av kunnskap er et naturlig svar på den iboende tendensen mot utvikling av stadig mer komplekse systemer Utviklingen går så raskt at det kan være vanskelig nok å holde følge med sitt eget fagfelt Spesialisering er en sterk kraft i effektiviseringsarbeid Fordelen med bred og tidvis overlappende kompetanse er ikke så åpenbar Det kan bli vanskelig å forsvare bruk av tid på oppgaver som ligger utenfor ens egen spesialitet Spesialisering truer breddekunnskapen

The Economist 2009:

Hvordan viser spesialisering seg? Spesialisering fester seg over tid i både sosiale og tekniske systemer: Begge vil gjerne forsterkes over tid og kan dermed overdrives. Spesialisering i sosiale systemer viser seg ofte i skarpe roller, adskilte grupper, lite overlappende kunnskap. Overdrevet spesialisering i tekniske systemer kan vise seg i lite integrasjon mellom del-systemer eller del-systemer med nær identisk funksjonalitet osv. Å motvirke denne spesialiseringen krever derfor aktiv ledelse, men hva kan gjøres i praksis?

Eksempel: Jobb rotasjon Betyr å rotere rolle (og oppgaver som hører med) ”På skift” eller mer sammensatte programmer Læring ved praksis Velkjent fra ledelseslitteraturen Man får innsikt i flere deler av virksomheten og ”ser helheten” Skape grunnlag for bedre beslutninger For å bedre innovasjon Økt grad av kobling mellom kunnskapsdomener For å motvirke monotoni Gir forandring, spenning, avveksling Også såkalte ”creative tensions”

Jobb rotasjon i systemutvikling Case: Rotasjon til support i en software SMB (Fægri et al. 2010) Support ble for ”personlig” og at utviklere ble fanget i support av egen kode 9 utviklere deltok, veldig korte perioder (1-2 uker på support) Rotasjon ble avviklet etter 18 uker Viktigste funn: Gapet mellom forventninger i supportrollen og kompetanse ble veldig stort for noen De korte syklusene gjorde at ”oppstart kostnaden” ble stor Support oppgaver hadde lav status og mange foretrakk at ”noen andre” jobbet med support (men holdningen til support var mer positiv blant de med lang erfaring) De fleste syntes det var interessant å lære om andre produkter Flere kommenterte at det var nyttig å ”se helheten” i porteføljen Stor oppslutning om å lage mer vedlikeholdbar kode Det ble skapt grobunn for nye løsninger T.E. Fægri, T. Dybå and T. Dingsøyr (2010). “Introducing knowledge redundancy practice in software development: Experiences with job rotation in support work,” Information and Software Technology 52(10): 1118-1132.

Planning Poker Velkjent og anbefalt teknikk fra Scrum og XP for gruppebasert estimering Folk deltar ved å velge et kort med et timetall som de mener er nærmest det oppgaven krever av tid Kortene vises samtidig Vesentlige avvik diskuteres og fører til repetisjon av øvelsen Bygger breddekunnskap; folk engasjerer seg i hverandres oppgaver

Planning Poker i en spesialistkultur Case: En utviklingsgruppe i en stor IT bedrift som slet med innføring av Scrum Spesialisering var forankret i både sosiale og tekniske systemer En betydelig barriere for teamarbeid – gruppa var egentlig ikke et team Det tok lang tid å få gruppa til å gå med på noe som ble ansett som en tidstyv Funn: Planning Poker gir en balanse mellom teoretisk og praktisk kunnskap Man må engasjere seg i estimatene, men blir ”ikke veldig møkkete på fingrene” Gode diskusjoner om løsningsstrategi Ganske rask synliggjøring av gevinst Teamet ble sterkere Tidligere usynlige teammedlemmer bidro med veldig viktig innsikt Planning Poker ble opprettholdt for ca ½ av oppgavene etter case studiet var avsluttet T.E. Fægri (2010). Adoption of team estimation in a specialist organizational environment. In Agile Processes in Software Engineering and Extreme Programming (11th International Conference, XP2010). A. Sillitti et al, eds. Berlin Heidelberg, Springer-Verlag. LNBIP 48: 28-42.

Noen råd Diskuter problemet og skap felles forståelse for situasjonen Strategi for læring (og utvikling av breddekunnskap) må samstemmes med teknisk strategi En bred portefølje øker kostnaden ved breddekunnskap og gjør teamarbeid vanskeligere Flere teknikker kan benyttes til utvikling av breddekunnskap Jobb rotasjon og Planning Poker er bare eksempler De bør også tilpasses lokale forhold Strategien for læring bør uttales tydelig Spesialisering er en sterk kraft fordi den lover kortsiktig effektivitet Effektivitetsidealet bør derfor utfordres åpent av strategien