In een recent webinar over het gebruik van onze SLIM-tools en -methodes in een agile omgeving zijn templates te zien voor agile projecten met SLIM-Estimate. Een deelnemer vroeg: “Agile teams hebben een vaste omvang en blijven bij elkaar gedurende het werk aan de release. Waarom gebruikt het agile template dan niet de Level Load opbouw (constante inzet van eenzelfde aantal mensen)?” Het typische korte antwoord op deze complexe vraag was: “Het is gecompliceerd en het hangt ervan af.” Laten we eens inzoomen op die complexiteit en afhankelijkheden.
Het team, het hele team of niets dan het team?
Bij het gebruik van SLIM-Estimate voor een inschatting van de inspanning die nodig is voor een release – agile of niet – moet je beslissen: in wiens inspanning zijn we eigenlijk geïnteresseerd? Bij het beschrijven van een team in een scrumproject, praten we meestal over drie belangrijke rollen: de producteigenaar, de scrummaster en het teamlid. Deze mensen werken doorgaans fulltime aan het project. Als u alleen de inspanning van deze leden wilt inschatten, dan kunt u de ‘Level Load’- vorm in SLIM-Estimate gebruiken. De totale inspanning van deze mensen is gebaseerd op het aantal personen vermenigvuldigd met de duur van het werk aan de volledige ontwikkeling en de uitrol.
Maar u wilt SLIM-Estimate wellicht gebruiken om een (in)schatting te maken van de totale inspanning die nodig zijn voor de release. Er zullen vrijwel zeker ook mensen zijn die op de achtergrond een bijdrage aan het project leveren. Zo vormen gesprekken over de user stories het hart en ziel van de scrummethode. Ze leiden uiteindelijk tot de juiste requirements. De eisen voor de release komen tot stand ??door middel van deze gesprekken. Hoewel de producteigenaar uiteindelijk bepaalt welke stories meegenomen worden, wijzen veel agile goeroes erop dat er veel mensen nodig zijn om de details in te vullen en de software te reviewen tijdens de bouw. Die detailinformatie ontstaat ??door middel van gesprekken met materiedeskundigen, proceseigenaren, klanten en andere belanghebbenden. Om het maximale voordeel van agile methodes te verkrijgen, heeft u deze belanghebbenden vanuit de business gedurende het hele project nodig, zodat de details van de requirements naar voren op het moment dat ze nodig zijn. Maar vaak kunnen de mensen niet fulltime aan het project bijdragen.
Het kan nodig zijn om rekening te houden met deze toenemende betrokkenheid om de werkelijke kosten van het project boven water te krijgen, zelfs indien, in meer waterval-achtige situaties, de inzet van deze stakeholders niet wordt gevolgd of gemeten. Ook zijn er vaak specialisten (zelfs in agile projecten!) die hun tijd aan meerdere projecten besteden. Deze mensen kunnen niet fulltime aan het project werken, maar het succes van de release is wel afhankelijk van hun deelname. U zult bij uw schatting van de benodigde inspanning dus rekening willen houden met hun inzet. Het op de juiste wijze gebruiken van de verschillende Rayleigh-vormen in SLIM-Estimate maken dat mogelijk.
Team van mensen of team van teams?
Grote organisaties oriënteren zich op standaard werkwijzen (frameworks) om agile-methoden toe te passen op grote projecten, programma’s en portfolio’s. Hoewel er veel van dergelijke frameworks zijn, gaan de meeste uit van het idee van ‘team van teams’ (of zoals het vaak wordt genoemd, ‘Scrum van Scrums’), elk team met de omvang van een typisch agile team van 7 man, soms 1 a 2 meer of minder. Er kunnen 5, 10 of meer van dergelijke teams samenwerken aan het project. Hoe sluit dit aan op de vormen van de inspanningscurves in SLIM-Estimate? Terwijl elk team bij elkaar kan blijven tijdens het werk aan het project, zou u teams toe kunnen willen voegen en verwijderen als het project dat vereist. (Let op: niet alle agile frameworks beschrijven het op deze manier.) Dus u kunt de bekende Rayleigh vorm zien m.b.t. staffing, maar uw staffing unit is dan ‘team’ in plaats van ‘persoon’. In plaats van individuele mensen op- en af te schalen zoals de Rayleigh curve voorspelt, zou u hele teams op- en afschalen. Voor een deel van de tijd kunt u een paar mensen meer of minder hebben ingezet dan de curve voorspelt, maar u krijgt wel het voordeel dat teamleden samenhangende eenheden vormen, en dat kan communicatieproblemen binnen het team verminderen en de productiviteit verbeteren.
Twee werktypes
SLIM-Estimate voorspelt de inspanning op basis van specifieke fase-instellingen (Fase Tuning). Een van de belangrijkste daarvan is welke fasen zijn inbegrepen. ‘Fase’ in SLIM-Estimate heeft een specifieke betekenis die van toepassing is op zowel agile projecten als op andere methoden. U moet bij ‘fasen’ meer denken aan ‘vormen van werk’ dan aan ‘opeenvolgende perioden’. Juist voor agile ontwikkeling, raad ik u aan ten minste twee typen werk te onderscheiden, in te schatten en te volgen: Story Writing (QSM fase 2)en Story development (QSM fase 3).
Story Writing omvat besluitvorming over welke stories moeten worden opgenomen bij het creëren van de agile user story cards. Het omvat ook de verfijning van story details, of die nou op papier staan, in elektronische vorm beschikbaar zijn of, zoals zoveel agile goeroes suggereren, helemaal niet opgeschreven zijn, maar tot uiting gekomen door middel van gesprekken tussen alle deelnemers. Het is wel essentieel dat dit werk als team wordt gedaan.
Story Development vertaalt de stories naar werkende software. Dit omvat coderen, testen, documenteren en alle andere activiteiten om de software voor te bereiden op de uitrol en gebruik. Dit wordt gedaan door het kernteam, samen met mensen in gespecialiseerde rollen die niet fulltime betrokken zijn, zoals ik eerder opmerkte.
In de SLIM-tools en -methoden, kunt u deze twee werksoorten afzonderlijk voorspellen en volgen. Als u kijkt naar hoe de totale inspanning tussen die twee is verdeeld vallen drie zaken op:
- Story Writing wordt vooral gedaan door mensen die niet fulltime bij het project betrokken zijn;
- De mensen die wel fulltime betrokken zijn verdelen hun tijd over de twee werksoorten onevenredig;
- De hoeveelheid werk die wordt besteed aan elk type werk is NIET constant gedurende het project.
Het resultaat is dat de vorm van deze twee soorten werk of fasen in het SLIM-Estimate het best kan worden voorspeld door Rayleigh-vormen, in plaats van Level Load. Welke Rayleigh vormen hangt weer sterk af van de kenmerken van uw methoden (kijk, daar is dat antwoord, “het hangt ervan af,” weer!). We hebben een aantal suggesties in onze agile template op basis van een aantal gemeenschappelijke patronen, maar mogelijk wilt u ze aanpassen.
Hoe past dit nou binnen het idee dat ‘het team fulltime bij elkaar blijft?’ Als u de Rayleigh curves combineert voor de verschillende fasen, krijgt u bijna de Level vorm. Het omvat fulltime aanwezigheid van de producteigenaar, scrummaster en teamleden voor de hele duur van het project, maar omvat ook de wisselende, parttime deelname van specialisten en al die mensen die de backlog verrijken en verfijnen.
Laten we eens kijken naar de veronderstelling dat een agile team een vaste grootte zou moeten hebben gedurende de werkzaamheden aan de release. Agile goeroes bepleiten dit staffing patroon met een goede reden. Agile gaat over teamcommunicatie en als het kernteam altijd bij elkaar is, vaak in dezelfde ruimte, kan dat optimale communicatie bevorderen. Het tegenargument is dat het een poging kan zijn om de resources maximaal te benutten. Als je mensen op- en afschaalt bij projecten op momenten dat ze nodig zijn, kan een persoon het werk afronden van verschillende projecten in plaats van te hoeven wachten tot er weer zinvol werk voor hem/haar is in een afzonderlijk project.
Wat te doen voor een goede voorspelling?
We zien dat om verschillende redenen, een eenvoudige Level Load vorm in SLIM-Estimate misschien niet altijd de meest geschikte is voor het voorspellen van agile projecten, zelfs als uw kernteam bij elkaar blijft. Wat is dan wel de juiste vorm die u moet gebruiken? U zou kunnen beginnen met de vormen voor de fasen in de SLIM Agile Story Point template die u ziet als u SLIM-Estimate installeert. Maar als u uw eigen organisatiegeschiedenis bekijkt en ziet welke staffingpatronen het nuttigst blijken voor uw verschillende agile methoden, zult u dat template mogelijk aan willen passen. U heeft wellicht zelfs verschillende templates nodig voor verschillende releasetypes.
Nieuwe producten of belangrijke innovaties op bestaande producten kunnen andere vormen nodig hebben dan kleine verbeterreleases. Bedrijfskritische projecten zouden juist meer ‘front loaded’-vormen nodig hebben voor Story Writing, zodat de mensen in de hele organisatie op tijd hun input kunnen geven. Er is geen eenvoudig, eenduidig antwoord dat zal werken voor elk agile-project. Immers, het is ingewikkeld en het hangt ervan af.
Hans Vonk