Når teamet bliver for stort

Scrum er designet til at virke med teams med en størrelse på 7 deltagere +/- 2. Dvs et team skal ikke overstige 9 deltagere, sker det skal man dele sig i to teams. Det kan give lidt mere overhead, men gør man erfaringer viser at et team på 10 deltagere ikke yder mere end et team på 9. Det vil altså sige at er man 10 deltagere på et team, er den ene person bare spild. Og hvordan kan det nu være?

Erfaring viser at et Scrum teams ydeevne pr. deltager falder hver gang der tilføres en ny deltager ud over de 7 deltagere og når man når til at tilføre den 10. deltager, så er koordiringesproblemet så stort at det for hele teamet koster en hel deltager. Så den 10. deltager yder selvfølgelig det samme som alle de andre 9 deltagere, men fordi teamet nu er så stort er der et koordineringsproblem der koster hver deltager en 10. del af sin ydeevne, hvilket jo svare til en hel deltager for hele teamet.

Jeg har selv deltaget i et team hvor bemandingen i perioder har svinget kraftigt, og vi har ligget og vaklet omkring smertegrænsen, og der er mange gange blevet snakket om at dele teamet, men det er altid kun blevet ved snakken, folk har simpelhen været for nervøse ved konsekvenserne af det – Vi ved hvad vi har, vi ved ikke hvad vi får.

Konskvensen af dette har så været at teamet er begyndt at ske forskellige ting i teamet. Fx. begyndte man at uddele ansvar istedet for at teamet bar det i fællesskab.

En anden ting det skete uden nogen beværkerede det var at dele sig selv op i mindre teams, som “hvis I tager den opgave så tager vi den her”, det var effektivt så længe der ikke var nogen der blev syge eller ikke var tilstedet af andre årsager, og så længe der forsat var noget at lave i alle opgaver, men når en opgaverne blev færdige en efter en, så kunne de personer der havde arbejdet på dem ikke bare træde til og hjælpe de andre færdige, for de kendte ikke deres opgaver. Hvilket gav i problem for man lige pludselig med nogen der havde travlt og nogen der ikke havde noget at lave men de kunne ikke hjælpe hinanden uden det ville betyde at alle ville få mega travlt fordi der nu også skulle bruges tid på at sætte de “nye” ind i opgaven. Problemet her er at teamet har commit’et sig til at have løst dette sæt af opgaver når sprintet er slut, og på papiret ser det stadig ud til at man kan nå det, der er fx opgaver til 50 mandetimer og man har 50 mandetimer til sprintet er slut – Det passer jo lige – Men nej, det gør det jo kun hvis alle kan yde effektivt i alle 50 mandetimer, men det er jo kun dem der iforvejen er igang med den opgave der kan være effektiv, resten har jo en opstartsperiode hvor de lige skal ind i hvar opgaven er, og denne opstartsperiode betyder jo også at dem der kender opgaven bliver sløvet i effektivitet fordi de skal have de andre med.

Havde det nu været to teams istedet, så ville alle i hver team kende alle teamet opgaver og alle ville kunne yde effektivt uden først at skulle sætte ind i opgaven. Det vil også betyde at hver team har commit’et sig til hver sin del af den store opgavepulje, så arbejdsbyrden passer med hvad det enkelte team kan nå i det pågældende sprint. Man ville altså kunne øge effektiviteten i det at man undgår spildtid.

Mit budskab er altså “del jer lige så snart i bliver mere end 9 deltagere” – begyndt allerede når i bliver mere end 7 deltagere at overvej om i vil være bedre tjent med at dele jer til to teams, så er i også bedre forberedt når i pludselig en dag får mand nr 10 med på teamet og i bliver nød til at dele jer for at holde effektiviteten.