Zodra de dagelijkse Scrum op een Flashmob begint te lijken, weet je dat het team te groot geworden is.
Als het om de grootte van schoolklassen gaat, dan is iedereen het er snel over eens: kleinere klassen zijn beter dan grote klassen. Het betekent meer aandacht voor de individuele leerling en daardoor een beter resultaat. Voor Scrum-teams geldt hetzelfde. Zodra de dagelijkse Scrum op een Flashmob begint te lijken, weet je dat het team te groot geworden is. Soms is het angst om te splitsen: men is bang het overzicht te verliezen. De neiging om er niet direct iets aan te doen komt vaker voor. Dat is onverstandig, want er zijn wel degelijk risico’s.
Transparantie
Even een stuk theorie. Eén van de drie Scrum-waarden is transparantie, wat ikzelf vertaal naar overzicht, duidelijkheid en eerlijkheid. Hoewel de woorden voor zich lijken te spreken, betekenen ze niet voor iedereen hetzelfde. Het is daarom verstandig om met enige regelmaat binnen het Scrum-team te bespreken wat en of alles overzichtelijk, duidelijk en eerlijk is.
Scrum is erop gericht om zelfsturende, autonome teams te creëren, waarbij de Scrum-guide teams van maximaal 9 personen voorschrijft. Om zo’n team succesvol te maken, zijn overzicht en duidelijkheid van groot belang: je kunt alleen correct acteren als je overzicht hebt en begrijpt wat je ziet. Als dat niet het geval is, dan zal snel blijken dat het team last krijgt van onvoorziene factoren die de voortgang belemmeren, zonder dat er een duidelijk aanwijsbare reden is. Hoe groter het team, des te lastiger het is om overzicht te houden.
Overzicht
Dat overzicht gaat over verschillende assen. Ten eerste het team zelf. Voor elk teamlid is het team beter te overzien als het compact is. In een team van 5 personen moeten in totaal 10* contacten onderhouden worden. In een team van 10 personen moeten 45** contacten onderhouden worden. Waar het team dus slechts verdubbelt, vergroot het aantal contacten in het team exponentieel met een factor 4,5. Een risico: minder aandacht per persoon, dus minder focus.
Ten tweede: de te realiseren user stories. Stel dat een team van 5 personen per sprint 10 user stories kan opleveren. Gedurende de sprint wordt elke user story doorgaans meerdere malen tijdens de daily scrum besproken, in elk geval tweemaal: bij de start en bij de afronding. Dat is 20 maal. Als het team 10 personen zou bevatten, zouden per sprint ongeveer 20 user stories opgeleverd kunnen worden. Ook hier wordt gedurende de sprint elke user story tenminste tweemaal besproken, in totaal dus 20 x 2 = 40 maal.
Tijdens de daily scrum heeft elk teamlid dus slechts de helft van de tijd beschikbaar per user story. Weer een risico: minder aandacht per user story en hierdoor minder duidelijkheid.
De derde as raakt een Agile Principle: de meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten. Een groter team genereert meer documentatie, veelal om te borgen dat iedereen over hetzelfde spreekt. Onderlinge communicatie met meerdere personen is lastiger, gaat vaak via e-mail en kan onduidelijkheid en fouten veroorzaken. Documenteren kost meer tijd, waardoor er minder tijd is voor het realiseren van de user stories. Ook documentatie kan verschillend geïnterpreteerd worden als er onvoldoende kwaliteitscontrole is. Het risico: meer documentatie en schriftelijke communicatie en minder persoonlijk contact.
Daarnaast is eerlijkheid een factor die mogelijk aangetast wordt wanneer een team groter wordt. Wanneer een teamlid te kampen heeft met een tegenvaller, dan is de kans aanwezig dat dit in een groot team tijdens de daily scrum niet of niet goed besproken wordt. Omdat er per teamlid minder tijd beschikbaar is, is het een menselijke reactie om het probleem te bagatelliseren of dat iemand zich probeert te verschuilen achter zaken waar je geen invloed op hebt. Het team is er dan te zeer op gefocust dat iedereen binnen de time-box aan het woord komt. Het risico: kwaliteitsverlies en instabiele opleveringen.
De oplossing
De oplossing mag duidelijk zijn: als het team te groot wordt, maak er dan twee kleinere teams van. Overweeg daarbij goed hoe dat efficiënt kan. Functioneel splitsen is een goede optie. Zorg er wel voor dat elk team geheel multifunctioneel blijft: het moet zelfstandig functionaliteit op kunnen blijven leveren. Hiermee creëer je zogenaamde Feature Teams. Het risico bij feature teams is dat als er meerdere teams dezelfde broncode gebruiken en niet op dezelfde wijze te werk gaan, dat er dan inconsistente broncode ontstaat, wat lastiger te doorgronden en te onderhouden is. Onderlinge afstemming tussen de teams is dus noodzakelijk!
Een andere optie is goed werkbaar wanneer er in het team enkele mensen zitten die zich voornamelijk bezig houden met het refinement-proces, bijvoorbeeld een analist, designer en architect. Zij kunnen prima gezamenlijk het team vormen dat zich focust op het verfijnen van de user stories. Zodra het nodig is, kunnen zij de hulp inroepen van de specialisten in het development-team. Zie hiervoor ook mijn eerdere blog over het refinement-proces. Ik heb weleens te horen gekregen dat dit ‘niet Agile’ zou zijn en vooral neigt naar ‘waterval’. Daar ben ik het geheel niet mee eens! Een user story moet nu eenmaal voldoende gerefined zijn, voordat deze in de sprint opgenomen kan worden. Met een sprintlengte van 2 weken ben je daarmee nog steeds zeer wendbaar.
Opsplitsen op competentie is geen goed idee, want daarmee creëer je teams die niet geheel zelfstandig werkende functionaliteit kunnen opleveren.
Als je gaat opsplitsen, is het goed om de variatie in de teams te behouden, op verschillende fronten. Ook is het verstandig om naar de personen zelf te kijken: sommigen hebben een klik met elkaar, anderen juist niet. Tot slot is het beter om een te groot gegroeid team in twee compacte teams op te delen en deze twee teams verder te laten groeien, dan om een nieuw team naast het bestaande team op te zetten. Alle leden van het bestaande team hebben het proces (als het goed is) goed tussen de oren en kunnen die kennis meenemen naar de twee nieuwe teams. Als er een nieuw team naast het bestaande team geplaatst wordt, is de kans groot dat zij in het proces gaan afwijken van het eerste team.
Spring zelf in de bres
Samenvattend zijn er meer risico’s dan je in eerste instantie zou verwachten. Hoe groter het team, des te minder persoonlijk contact, minder focus, minder aandacht per user story, minder duidelijkheid, meer documentatie, meer schriftelijke communicatie, kwaliteitsverlies en instabiele opleveringen. Als je deze opsomming zo ziet, zou je wel even achter je oren mogen krabben als je development team 10-koppig wordt.
Als het om een te grote klas met kinderen gaat, dan staat of staan er voor elk kind één of twee ouders (of verzorgers) paraat die op de bres springen zodra de resultaten achter blijven. De kans is aanwezig dat het aan de grootte van de klas ligt. In de dagelijkse praktijk op de werkvloer zal elk teamlid zelf op de bres moeten springen. Praat erover met elkaar wanneer je de symptomen herkent. Niet twijfelen, maar splitsen!
(*): In een team van 5 personen moeten 4 + 3 + 2 + 1 = 10 contacten onderhouden worden
(**): In een team van 10 personen moeten 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 = 45 contacten onderhouden worden.
