Reliable Scrum
De gecombineerde voordelen van ToC èn van Scrum krijg je als je de principes uit ToC-projectmanagement en Scrum op de juiste manier met elkaar combineert. Hoe je dat het beste doet is afhankelijk van de situatie..
Agile benaderingen en met name Scrum hebben in de afgelopen paar jaar in sneltreinvaart vaste voet aan de grond gekregen bij de aanpak van ICT-projecten. Wat mij wel zorgen baart is dat de toepassing ervan nogal eens lijkt door te slaan. Mede onder invloed van zogeheten agile-implementers en agile-coaches, die Agile schijnbaar als de enige geschikte benadering uitdragen, worden oude benaderingen zonder meer aan de kant geschoven en worden alléén nog maar Agile technieken gebruikt. Wee degene die de euvele moed heeft zich daarover kritisch uit te laten. Hij/zij wordt maar al te gemakkelijk weggezet als “ouderwets” en/of als iemand die Agile niet begrijpt. Welnu, als dat kennelijk ervoor nodig is om op basis van gezond verstand je punt te kunnen maken zal ik het ruiterlijk toegeven: Ik ben ouderwets!! Ik ben er groot voorstander van om eerst met gezond verstand naar de klus te kijken die geklaard moet worden alvorens we de gereedschappen kiezen om het uit te voeren.
Hoezeer ik de toepassing van Scrum ook van harte toejuich, (Echt waar!! Om redenen die ik in een ander artikel op deze blog graag nog eens toe zal lichten..) de realiteit in ICT projecten is vaak aanzienlijk complexer dan de door Agile benaderingen geboden sturingsmogelijkheden aankunnen. In mijn ogen verzuimd Scrum dan ook invulling te geven aan een aantal behoeften rond deze (complexe) projecten. Dat zijn bijvoorbeeld:
- Borging van en heldere (project-) communicatie over realiseren business goals
- Input voor resourcemanagement en ketenbesturing in multi-project omgeving
Verschillende organisaties die op het gebied van ToC-projectmanagement in de ICT actief zijn pogen in deze behoeften te voorzien door de ToC-principes te combineren met Scrum. Zij noemen dit Reliable Scrum. Dat zijn bijvoorbeeld het Duitse Speed4projects en in Nederland Garansys en Reliable Projects. (Reliable Projects is overigens niet de bedenker van de term Reliable Scrum. Hooguit onderstreept het dat de bedrijfsnaam van Reliable Projects goed gekozen is.)
Zinvolle toepassing van Reliable Scrum is afhankelijk van de context waarbinnen Scrum gebruikt wordt. Ik denk dat je daarbij onderscheid kunt maken in 4 categorieën die ik hieronder uitwerk.
1. Software onderhoud
Bij onderhoud van bestaande in gebruik zijnde software kan in principe na elke sprint een nieuwe release in gebruik genomen worden. Software onderhoud leent zich daarom uitstekend voor toepassing van Scrum as is.
2. Multiple sprint softwareontwikkeling
Als er meerdere sprints van een sprintteam nodig zijn voordat de aangepaste/nieuwe software in gebruik genomen kan worden, dan is er sprake van multiple sprint softwareontwikkeling.
Scrum ondersteunt de sturing bij multiple sprint softwareontwikkeling doordat je met behulp van een velocity trendline en een work added/removed trendline uitspraken kunt doen over de periode waarin de aangepaste/nieuwe software in gebruik genomen kan worden. Voorwaarde voor het kunnen gebruiken van deze trendlines is dat de stories op de product backlog de beoogde aanpassingen min of meer volledig afdekken en dat de storypoints voor alle stories geschat zijn. Deze randvoorwaarde staat enigszins op gespannen voet met de Agile gedachte dat je vooral niet te ver (meer dan 1 of 2 sprints) vooruit moet willen kijken omdat er naar verwachting toch nog veel voortschrijdend inzicht zal zijn waardoor zowel de productbacklog als de schattingen drastisch aangepast zullen moeten worden.
Bij toepassing van Reliable Scrum worden buffering principes gebruikt om aan de hand van voortgang en bufferverbruik de projecteinddatum te bewaken. Een eenvoudige spreadsheet volstaat al om dat mogelijk te maken.
3. Multiple sprintteam softwareontwikkeling
Als er meerdere sprints van meerdere sprintteams nodig zijn voordat de aangepaste/nieuwe software in gebruik genomen kan worden dan is er sprake van Multiple sprintteam softwareontwikkeling.
In Scrum projecten wordt ten behoeve van de sturing naast de trendlines zoals besproken bij Multiple sprint softwareontwikkeling nu doorgaans ook gebruik gemaakt van een coördinatieoverleg in de vorm van een zogeheten Scrum of Scrums. Een goed praktijkgebruik is om de uiteenlopende sprintteams zo mogelijk parallel te schakelen en tegelijkertijd aan dezelfde stories te laten werken. Op deze wijze wordt zoveel mogelijk vermeden dat teams last hebben van onderlinge afhankelijkheden.
Toegegeven: Met goede coördinatie en het parallel schakelen van de sprintteams kan je een eind komen. Mits de onderlinge afhankelijkheden overzichtelijk blijven en de doorlooptijden de sprintduur niet overschrijden.. Dreigt dat wel het geval te zijn, dan is het advies vanuit Reliable Scrum om de taakafhankelijkheden in een Gantt-planning uit te werken. Dit wil niet zeggen dat de werkaansturing nu gaat plaatsvinden vanuit de Gantt. Dit is slechts een hulpmiddel om de grote complexiteit aan afhankelijkheden in kaart te brengen en mede zodoende te bepalen welke activiteiten in welke sprints moeten worden ondergebracht.
4. Complex project met gedeelte softwareontwikkeling
Vinden er in het project naast softwareontwikkeling een veelheid aan activiteiten plaats die zich er niet voor lenen om in sprints uitgevoerd te worden, dan is er sprake van een complex project met een gedeelte softwareontwikkeling.
Scrum biedt voor dergelijke situaties geen specifieke voorzieningen. Reliable Scrum hanteert voor complexe projecten met een gedeelte softwareontwikkeling een hybride aansturing van de activiteiten. Sprints (eventueel van meerdere sprintteams) en alle overige projectactiviteiten worden naast elkaar ondergebracht in een gebufferde Gantt-planning. De aansturing van de softwareontwikkeling vindt plaats volgens de Scrum principes waarbij met behulp van de trendlines wordt gerapporteerd over de voorgang en over de remaining work. Zodoende heeft de voortgang in de softwareontwikkeling zijn weerslag in het bufferverbuik van het totale project. De aansturing van de overige activiteiten vindt plaats rechtsreeks vanuit de gebufferde Gantt-planning. Zodoende kan op elk moment betrouwbare informatie worden verstrekt over de haalbaarheid van de projecteinddatum.
Hieronder kunt u desgewenst reageren op dit artikel. Mocht u naar aanleiding van een of meer artikelen in deze blog vragen hebben en/of rechtstreeks met mij contact willen opnemen, schroomt u dan niet een e-mail bericht te sturen naar info@reliableprojects.nl
Categories: Agile, ToC-Projectmanagement