Een handleiding voor realistische Agile/Scrum implementaties

maart 2017 – de officiële Agile/Scrum guide beslaat maar 18 kantjes. Het is daarom niet zo gek dat er veel verschillende beelden bestaan hoe Scrum in de praktijk werkt en hoe je Scrum implementeert.

Dogmatici zeggen dat er maar 1 goede implementatie bestaat en al het andere geen Scrum is. In deze ideale implementatie heb je 1 multi disciplinair team, 1 product owner die alles weet en kan en je levert iedere Sprint een werkend product op.
Idealisten begrijpen wel dat de werkelijkheid kan afwijken van dat ene ideaalbeeld, maar dan is het noodzaak om naar dat ene ideaalbeeld toe te werken.
Een andere variant komt ook voor. Het doet er niet toe hoe je Scrum implementeert, het gaat er om dat je leert en blijft leren. Dan komt alles wel goed.

Figuur 1: ideaal Scrum in een ideale omgeving

Het zal u niet verbazen dat vanuit zulke overtuigingen niet iedere Scrum implementatie even succesvol verloopt.  Wij nemen u graag mee in onze ervaringen bij het wel succesvol implementeren van Scrum.

Het begint met gezond verstand

Voor succesvolle implementaties is het nodig om realistisch en met gezond verstand te kijken naar wat de theorie ons aanreikt aan hulpmiddelen.

Ieder model is een vereenvoudigde weergave van de werkelijkheid

Ieder project en iedere klantomgeving is uniek. Hoe gedetailleerder het model is, hoe onrealistischer het is dat het model 1 op 1 geïmplementeerd kan worden. Dat is juist de reden dat Scrum model als raamwerk is neergezet. Het is een kapstok die je op maat moet inrichten en aankleden. De in de Scrum guide beschreven werkwijze is inderdaad een ideaalbeeld in een ideale omgeving, maar wat je nodig hebt is een ideaalbeeld in de eigen omgeving.

Veranderen is een reis die start vanuit een begin

Veranderen is moeilijk. Ook het leren werken vanuit Scrum is een verandering. Het is onrealistisch om te verwachten dat je in 1 keer een 100% perfecte Scrum implementatie hebt. Het is verstandig om goed uit te zoeken hoe de processen in het heden plaatsvinden en van daaruit de volgende stap te bepalen.

Het is dus belangrijk te starten vanuit het heden, met een realistische blik op wat het ideaalbeeld zou kunnen zijn. Wat voor mogelijkheden biedt Scrum ons dan om implementatiekeuzes te maken?

Scrum implementatiekeuzes

In het Scrum raamwerk staan veel zaken vast, maar op een aantal vlakken is een nadere invulling nodig:

De Definition of Done (DoD)

De DoD geeft aan aan welke eisen de producten moeten voldoen die in een Sprint worden opgeleverd. Een voorbeeld kan zijn: “De opgeleverde producten zijn getest conform de aangegeven acceptatiecriteria en de producten voldoen aan deze criteria”.
Wat er precies in de DoD staat is afhankelijk van de situatie.

De Definition of Ready (DoR)

De DoR geeft de acceptatiecriteria van het team aan. Deze acceptatiecriteria beschrijven de eisen waaraan de Product Backlog Items (PBI) moet voldoen voordat het team in staat is dat werk op te pakken in een Sprint. Een eenvoudig voorbeeld zou kunnen zijn: “Wij begrijpen het PBI goed genoeg, hebben op basis van deze kennis het PBI geschat in omvang en zijn daardoor redelijkerwijs in staat het PBI binnen de Sprint op te leveren, in samenhang met de andere Ready PBI’s”.
Wat er precies in de DoR staat is afhankelijk van de situatie.

Stakeholder management achter de Product Owner (PO)

De Scrum guide geeft aan dat de PO altijd maar 1 persoon kan zijn. Dat is belangrijk om effectief met het team te kunnen samenwerken. Deze ene PO is wel verantwoordelijk voor het afdekken van alle belanghebbenden bij het te realiseren product. Scrum zegt wel dat er maar 1 persoon de PO kan zijn, maar zegt niet hoe die PO ondersteund kan worden. Hier ligt een grote uitdaging en tegelijkertijd een hele wereld aan implementatiekeuzes open.

Op basis van de hierboven aangegeven uitgangspunten en handvaten is onderstaand stappenplan mogelijk. Disclaimer: ook dit stappenplan is een vereenvoudigde weergave van de werkelijkheid.

Stappenplan

Definiëer het eindproduct

Stel vast aan welke eisen het eindproduct moet voldoen. Wie beheert het product? Wie gebruikt het product? Wat zijn de daarbij behorende eisen en verwachtingen?
Deze inventarisatie levert een eerste versie op van de DoD.

Hoe ver kan je realistisch gezien gaan in een Sprint?

Idealiter lever je vanuit iedere Sprint een deelresultaat op wat onmiddellijk in gebruik genomen wordt. Alhoewel dat een belangrijk streven is, moeten we rekening houden met wat nu in de werkelijkheid realistisch mogelijk is. Er zijn vaak veel activiteiten die moeten plaatsvinden tussen het moment dat een product gerealiseerd is en het moment waarop het product gebruikt wordt. Het is niet realistisch dat al die activiteiten kunnen plaatsvinden binnen de scope en tijdsspanne van een Sprint.

Figuur 2: de business kan niet accepteren in hetzelfde tempo als IT kan opleveren. Een vaak voorkomend probleem.

De scope van een Sprint wordt beperkt tot die activiteiten die wel afgerond kunnen worden in de Sprint. De DoD wordt hierop aangescherpt, zonder echter het oog te verliezen op de eisen die gesteld worden aan het eindresultaat. Vaak zijn er meerdere Sprints nodig totdat opgeleverd kan worden naar het volgende team. Er moeten afspraken gemaakt worden met dat team of de afdeling die het resultaat van een Sprint gaat oppakken.

Een minder vaak voorkomende variant is dat er “realisatiesprints” zijn die gevolgd worden door een “implementatie/beheersprint”. Dit is niet altijd de handige keuze als het moeilijk is om acceptatie/beheer/implementatie af te ronden binnen de tijdsspanne van de sprint.

Wat is er voor nodig vóór de start van een Sprint om het werk binnen de scope van een Sprint af te kunnen ronden?

Idealiter is er zo weinig mogelijk voorbereiding nodig. Het team kan samen met de PO de inhoud van de Product Backlog voorbereiden tot het niveau dat goed genoeg is om het werk in een Sprint op te kunnen pakken en af te kunnen ronden.

Een voorbeeld van zo’n situatie zou een reclamebureau kunnen zijn dat een TV commercial maakt. Na een initieel gesprek met de opdrachtgever is voldoende informatie beschikbaar voor de eerste Sprint. Bij de Sprint Review worden opmerkingen verwerkt en in de volgende Sprint wordt het filmpje aangepast. Een passende en effectieve werkwijze met minimale overhead.

Meestal is er meer nodig dan een gesprek om de werkvoorraad Ready te krijgen. Hoevéél nodig is hangt af van de situatie. Bij een Business Process Redesign project moet je eerst wel een idee hebben hoe de processen gaan verlopen. In de meeste gevallen moet een basis zijn neergelegd in een Project Start Architectuur. De detaillering van deze PSA kan vervolgens gedurende de opeenvolgende Sprints plaatsvinden, waarbij toch nog analyse en ontwerp activiteiten plaatsvinden.

Figuur 3: Het probleem is te complex om zonder voorbereiding op te kunnen pakken in een Sprint.

De Definition of Ready wordt vastgesteld op basis van wat het team nodig heeft om te kunnen starten, maar óók op basis van wat mogelijk is in de aanlevering. Bij een Europese Aanbesteding met een compleet uitgewerkt bestek kan je wel om een Scrum uitwerking van de requirements in de vorm van User Stories vragen, maar die ga je niet krijgen. Wat je wel kan doen is de aangeleverde specificaties indelen in brokken en die oppakken in Sprints.

Bepaal de ondersteuning voor de Product Owner

Scrum geeft aan dat de PO 1 persoon moet zijn. Deze PO stuurt op het maximaliseren van waarde door het aanbieden van werkpakketten (Product Backlog Items) en de prioritering van deze werkpakketten. Iets traditioneler verwoord stuurt de PO op scope, tijd en geld.

In veel projecten en programma’s liggen deze verantwoordelijkheden niet bij 1 persoon. Niet per se omdat een methode zoals bijvoorbeeld PRINCE2 dat voorschrijft (Executive, Senior User, Senior Supplier), want ook hierin zijn keuzes mogelijk, maar omdat de situatie daar om vraagt. De essentie van de insteek van Scrum is dat er effectief gestuurd wordt. Daarvoor is het echter niet nodig dat altijd en in alle gevallen het bij de inzet van die ene PO moet blijven.

Er zijn meerdere varianten mogelijk. Enkele voorbeelden:

  • Er bestaat een stuurgroep boven het Scrum team. De Senior User in de stuurgroep is de PO. De Senior Supplier is verantwoordelijk voor de kwaliteit en inzet van mensen in het team. De PO is manager van de mensen die de oplossing gaan gebruiken en stuurt op de scope van het product. De Executive is een hogere manager of directeur en gaat over tijd/geld.
  • De Product Owner is niet altijd beschikbaar voor het team, maar maakt wel de belangrijke keuzes. De PO creëert een team van business mensen onder zich die binnen vastgestelde grenzen het mandaat hebben om keuzes te maken.

Het is ook hier belangrijk om de essentie achter Scrum te begrijpen en op basis daarvan implementatiekeuzes te maken. Een dogmatische benadering van de invulling van de rol van de PO levert niet de gewenste resultaten op.

Ga samenwerken op de grenzen van Scrum

De onderdelen die niet in de scope van een Sprint worden uitgevoerd vallen in principe buiten het zicht van het Scrumteam. Hiermee ontstaan klassieke risico’s die je in het ideaalbeeld van Scrum niet had gehad. Bijvoorbeeld ontstaat het risico dat in het ontwerp zaken gevraagd worden die niet of moeizaam gerealiseerd kunnen worden. Of dat het team het ontwerp anders interpreteert en verkeerde oplossingen realiseert. Of er ontstaan testbevindingen die met een extra uitleg niet nodig waren geweest.

De Scrum oplossing voor dit soort problemen zit in de combinatie van samenwerken, incrementeel en iteratief opleveren/gebruiken en het continu leren en verbeteren. Er kan echter ook in de niet ideale situatie samengewerkt worden. Niet zo direct en kort op de bal als in Scrum, maar het “over de schutting” gooien gaat zeker niet helpen.

Enkele voorbeelden:

  • Ontwikkelaars en testers bespreken regelmatig concept ontwerpen. De inzichten die ontstaan helpen om realiseerbare ontwerpen te maken en helpen om de ontwerpen juist te interpreteren.
  • Gebruikers bekijken versies van de software die in de systeemtestomgeving draaien. Er is geen sprake van een acceptatietest, maar toch kan er al feedback gegeven worden.
Figuur 4: samenwerking over de formele grenzen
Leg keuzes uit

Een aanvullende belangrijke stap is dat de gemaakte keuzes worden uitgelegd. Ook de mensen in het team en de stakeholders daar omheen hebben bepaalde beelden wat kan en mag in Scrum. Keuzes die mensen niet begrijpen leiden tot weerstand en frustratie.

Conclusie

Eigenlijk is de boodschap van dit whitepaper een universele boodschap in verandertrajecten. Staar je niet blind op modellen. Maak op basis van de essentie van het model keuzes die passen bij de situatie. Stel realistische doelen. Werk stap voor stap naar dat doel toe. Leg uit en ga een dialoog aan.

Het lastige met Scrum is dat de filosofie achter Scrum, namelijk waarde creëren en zelfsturende teams, al snel leidt tot idealisme en onrealistische verwachtingen. Wellicht dat we over een jaar of 5 allemaal veel nuchterder kijken naar Scrum en dit whitepaper niet meer nodig is.