In elk bedrijf dienen prioriteiten te worden gesteld als het gaat om welk werk het meest belangrijk is om als eerste te worden uitgevoerd. “Werk” is nogal een breed begrip en veelal wordt onderscheid gemaakt naar het primaire en secundaire proces c.q. welk werk doen we direct voor onze eindklanten en welk werk we doen om dat primaire werk mogelijk te maken.
Binnen het Scaled Agile Framework van SAFe wordt daarbij gekeken naar de “weighted shortest job first” (WSJF). De kosten van vertraging die daarbij kunnen optreden worden daarbij als leidend gezien bij het bepalen van de prioriteit van het werk.
In het model worden de prioriteiten in hoofdzaak op het portfolio niveau bepaald en het gaat daarbij om de grote ‘brokken werk’ c.q. epics. Een epic is bijvoorbeeld een nieuw product of een product verbetering voor onze eindklant. Het kan ook gaan om uitbreiding of verbeteringen in het secundaire proces en vanuit het SAFe framework gaat het dan veelal om ICT projecten en programma’s.
Duidelijk is dat onze zelfsturende scrum teams aansturing behoeven over welk ICT werkzaamheden zij als eerste moeten gaan oppakken. De voornoemde epics worden opgebroken in kleinere stukken werk c.q. die worden opgebroken in features en stories. Features zijn te beschouwen als functionele onderdelen binnen een project die vervolgens worden opgesplitst in stories. Deze stories zijn zodanig qua omvang dat ze door een scrum binnen een sprint kunnen worden gerealiseerd. Een sprint heeft een duur van 1 tot 4 weken en vanuit het SAFe model een voorkeur voor een periode van 2 weken.
Top-down kan het proces van prioriteitstelling en het opbreken van werk beginnen bij epics en vervolgens naar features en stories als een trechter worden beschouwd. Het managen van deze trechter is een uitdagende management klus waarvoor het SAFe Framework tal van ‘best practice’ voorbeelden en adviezen geeft.
De ‘kosten van vertraging’ worden binnen het Framework aangeduid als de ‘cost of delay’ en refereert aan de denkwijze van Don Reinertsen. Hij focust daarbij op de business waarde van kleine brokken werk die relatief snel kunnen worden opgeleverd. Daarvoor is uiteraard de ‘business value’ van belang die het werk oplevert naast de ‘time criticality’ ervan. Tevens wordt gekeken naar de waarde of mogelijkheden die de oplevering van het werk biedt aan ander nog op te leveren werk en welke risico’s we ermee ondervangen. Deze optelsom wordt vervolgens gedeeld door de investering die we in het werk hebben te doen en die kan worden uitgedrukt in het aantal sprints die ervoor nodig zijn of het aantal story points ervan.
Bij deze rekensom gaat het niet om het afzonderlijke geval, maar gaat het om het kunnen vergelijken van meerdere projecten in termen van epics of features. Het vergelijken daarvan is iets dat in teamverband gebeurt en waarbij de deelnemers in onderling overleg komen tot een ‘acceptabel vergelijk’. Inschatting van ‘business value’ en ‘risk reduction’ is uiteraard mensenwerk en subjectief. De objectiviteit wordt nagestreefd door het in onderling overleg eens te worden met elkaar over welke waarden waaraan kan worden toegekend.
De crux in deze werkwijze zit in het creëren van ‘een trechter met een goede doorstroom’, waarbij voor de diverse betrokkenen op portfolio en programma niveau de prioriteitstelling duidelijk is. Daarbij kan het werk (features/stories) vlot worden afgeleid vanuit de epics en worden doorgegeven aan de scrum teams op team niveau voor de realisatie tijdens de sprint(s). De transparantie van deze trechter wordt behouden door deze werkwijze frequent uit te voeren, bijvoorbeeld als voorbereiding op elke komende sprint. Zodoende is bij aanvang van elke sprint duidelijk welk werk als eerste kan worden opgepakt en dat de juiste prioriteiten nog steeds worden gesteld.
Voor het management zit de uitdaging erin om deze werkwijze steevast te blijven herhalen , zodat voor de betrokkenen op de diverse niveaus een acceptabele, herkenbare en transparante prioriteitstelling van de werkzaamheden bekend is.