Hoe zorg je ervoor dat je als organisatie digitale innovaties snel kunt realiseren? In deze blogreeks leer je hoe agile werken je hierbij helpt. De wereld om ons heen verandert sneller dan ooit tevoren. Onder andere automatisering en digitalisering hebben ervoor hebben gezorgd dat ontwikkelingen elkaar snel opvolgen. Om als organisatie deze veranderende wereld bij te kunnen houden, is het belangrijk om wendbaar of agile te zijn. Door wendbaarheid kun je relevant blijven in een steeds snellere, digitale en globaliserende wereld. Het is het vermogen om snel in te spelen op veranderingen, ontwikkelingen, omstandigheden en klantvragen. Het helpt je daarnaast om digitale innovaties door te voeren en succesvol te laten landen binnen de organisatie. Een randvoorwaarde om wendbaar te zijn is het lerend vermogen van de organisatie.

Back 2 basics 

In de eerdere blogpost “De noodzaak van een lerende organisatie” hebben we geconstateerd dat door middel van het verrijken van de Plan – Do mindset met concepten als Iteraties en Inspect & Adapt organisaties zich langzaam transformeren naar lerende organisaties. In deze blogpost kijken we naar de complexiteit van het toevoegen van Inspect & Adapt binnen bestaande organisaties en gaan we daarom terug naar de absolute basis van een lerende organisatie. 

Het klinkt zo eenvoudig: werk in kortere iteraties en voeg Inspect & Adapt toe om een lerende organisatie te creëren. De praktijk is echter weerbarstiger en leidt tot veel nieuwe uitdagingen waar we mee te maken krijgen. Bijvoorbeeld, wanneer is een product (voldoende) klaar als we daar in een continue flow van iteraties steeds aanpassen? Wanneer gaan we over van Change the Business naar Run the Business? Hoeveel budget hebben we nodig als we niet exact kunnen bepalen hoe het eindproduct er uit ziet? Hoe bepalen we of nieuwe ontwikkelingen nog in de scope van onze originele business case vallen? En als we continu opnieuw afwegen of verdere ontwikkeling de investering waard is hebben business cases dan überhaupt nog waarde? 

Om duidelijk te krijgen wat het betekent om een lerende organisatie te worden, gaan we terug naar de absolute basis van een lerende organisatie. Wat als we slechts één klein product ontwikkelteam zouden hebben binnen onze organisatie? Welke mensen hebben we dan nodig? Welke activiteiten moeten worden uitgevoerd? Welke meetings zouden dan belangrijk zijn? En welke hulpmiddelen worden dan gebruikt? Door bij de absolute basis te beginnen en stap voor stap de vraag op te schalen, zijn we in staat om de onderliggende uitdagingen één voor één te adresseren. 

Als we het product ontwikkelteam willen optimaliseren op het leveren van maximale waarde en maximale wendbaarheid, kom je al snel uit bij het Scrum framework. Scrum is een ultra-efficiënt framework waarbinnen mensen complexe adaptieve problemen adresseren, waarbij op een creatieve en productieve wijze producten van de hoogst mogelijke waarde geleverd.  

Scrum is ultra-efficiënt omdat alles behalve de absolute bare essentials uit het Scrum framework weg zijn gelaten. Met andere woorden, als je meer elementen weg laat dan de enkele aspecten die Scrum voorschrijft, dan heeft dit een sterke negatieve impact op het bewegen naar een lerende organisatie. Vanuit onze ervaring kunnen we deze stelling zeker onderschrijven. In veel gevallen blijken product ontwikkelteams die moeite hebben met het werken volgens Scrum vaak één of meer onderdelen van het framework niet ingevuld te hebben dan wel op een verkeerde wijze uitvoeren.

Om complexe problemen te begrijpen, laten we eerst kijken naar het domein van simpele en gecompliceerde problemen. In deze domeinen bestaat minstens één goed antwoord die soms eenvoudig en soms moeilijk te achterhalen zijn. In het domein van complexe problemen daarentegen kunnen oorzaak en gevolg alleen achteraf worden afgeleid en zijn er geen goede antwoorden. Dave Snowden and Mary E. Boone, grondleggers van het Cynefin framework, beschrijven beide probleemdomeinen als het verschil tussen een Ferrari (gecompliceerd probleem) en het Braziliaanse regenwoud (complex probleem). Ferrari’s zijn gecompliceerde machines, maar een deskundige monteur kan er een uit elkaar halen en weer in elkaar zetten zonder iets te veranderen. De auto is statisch en het geheel is de som van zijn onderdelen. Het regenwoud als complex domein daarentegen is voortdurend in beweging – soorten sterven uit, weerpatronen veranderen, een landbouwproject leidt een waterbron om – en het geheel is veel meer dan de som der delen.

Adaptieve problemen kenmerken zich doordat het probleem beetje bij beetje kan worden opgelost. Een bekend voorbeeld hiervan is het probleem van het dagelijks moeten verplaatsen tussen de thuis en werklocatie (bijvoorbeeld wanneer thuis werken geen optie is). Het probleem is adaptief van aard omdat ik wanneer ik mijzelf met een fiets verplaats ik over het algemeen sneller tussen beide locaties kan verplaatsen. En wanneer ik daarna een elektrische aandrijving toevoeg, ik minder moe op de doellocatie aankomen. En wanneer ik daar een dak aan toevoeg ik ook nog eens droog aan kan komen. Kortom, er zijn verschillende tussenstappen mogelijk die het probleem beetje bij beetje oplossen en verschillende voor- en nadelen ten opzichte van elkaar hebben. 

Het op creatieve en productieve wijze leveren van producten van de hoogst mogelijke waarde is het gevolg van de beweging die we in de eerste blogpost hebben beschreven. Door de steeds korter wordende iteratie periode richten we ons meer en meer op die aspecten die de hoogst mogelijke waarde leveren. Door deze korte iteratie cyclus moeten we binnen de beschikbare tijd een hoge mate van productiviteit hebben. Immers, hoe meer we van de beschikbare tijd gebruiken voor aspecten die niet bijdragen aan het doel van de iteratie of het als team beter worden in de uitvoering, hoe minder voortgang we kunnen boeken in het oplossen van het probleem, hoe minder feedback kan worden opgehaald en hoe minder we in staat zijn om te leren.  

In essentie bestaat het Scrum framework uit tien essentiële onderdelen: één aan het eind van de iteratie werkend product, twee planningshulpmiddelen, drie rollen en een viertal overlegvormen.  

Scrum werkt met sprints, iteraties met een maximale lengte van een maand. Het aan het eind van elke sprint gerealiseerde én werkende product wordt in Scrum een potential shippable product increment genoemd. Een product increment omdat we elke iteratie weer, de dan belangrijkste, wensen vanuit het stakeholder veld toevoegen aan het bestaande product. Potential shippable omdat het team wat aan het product increment werkt aan het eind van de sprint een kant-en-klaar product oplevert die uitgeleverd moet kunnen worden zonder dat er verder nog actie vanuit het team voor nodig is. Of het product ook daadwerkelijk wordt uitgeleverd, is daarin niet van belang; dit besluit wordt alleen gebaseerd op het feit of het uitleveren van het product increment voldoende waarde heeft die de implementatie rechtvaardigt. 

De wendbaarheid binnen Scrum wordt ondersteund door een tweetal planningshulpmiddelen. De lange termijn “stip op de horizon” wordt vorm gegeven in de product backlog. Deze lijst beschrijft hoog over welke functionele behoeften nog moeten worden ingevuld ten aanzien van het product. Hoog over zodat weinig tijd wordt geïnvesteerd in het uitwerken van allerlei details die op dit moment nog niet relevant (en mogelijk door de tijd heen ook niet meer relevant worden). Met andere woorden, des te hoger de behoefte op de product backlog komt te staan, des te groter de kans is dat deze op korte termijn wordt opgepakt. De korte termijn “wat gaan we de komende sprint realiseren” wordt vorm gegeven in de sprint backlog en beschrijft de activiteiten die nodig zijn om het korte termijn doel te realiseren; het doel die past bij de hoogst geprioriteerde items op de product backlog.  

In Scrum worden slechts een drietal rollen onderkent: de product owner, het product ontwikkelteam en de scrum master. De product owner bepaalt WAT het product is en WAT aan het product increment wordt aangepast en is verantwoordelijk dat het Scrum team continu werkt aan die aspecten die de hoogste waarde representeren. Het product ontwikkelteam bepaalt HOE het product wordt ontwikkelt en HOE het product increment wordt aangepast om nieuwe behoefte in te gaan vullen. Het product ontwikkelteam is daarbij verantwoordelijk voor de kwaliteit van het product increment. De scrum master heeft binnen Scrum een management functie en ondersteunt op WELKE wijze het Scrum team het product increment realiseert. Hij of zij is daarbij verantwoordelijk dat het Scrum team de essentiële onderdelen goed begrijpt en op een effectieve manier uitvoert en de organisatie leert hoe zij op een effectieve manier met het Scrum team moeten samenwerken.  

Binnen een sprint zijn een viertal overlegvormen waar te nemen. Elke sprint begint met een sprint planning. Dit is een overleg waarin de product owner en het product ontwikkelteam gezamenlijk het doel voor de komende sprint bepalen en kijken welke behoefte vanuit de product backlog daarmee worden ingevuld. Daarna wordt gekeken hoe het product increment moet worden aangepast om het sprint doel te bereiken en welke randvoorwaarden daarvoor eventueel moeten worden ingevuld. Gedurende de sprint komt het product ontwikkelteam dagelijks bijeen tijdens de daily scrum om het werk voor de komende 24 uur te bepalen, en inzicht te krijgen in de voortgang ten aanzien van het sprint doel en het afronden van het werk van de sprint backlog. Aan het eind van de sprint wordt tijdens de sprint review het product increment door de stakeholders bekeken en feedback opgehaald over het huidige product increment en de aspecten die op korte termijn de meeste waarde toevoegen. Op basis van deze feedback kan de product owner besluiten de product backlog aan te passen door nieuwe behoeften toe te voegen, de prioriteit en daarmee de volgorde van de behoefte aan te passen dan wel behoeften van de product backlog te verwijderen. De laatste essentiële overlegvorm binnen Scrum is de sprint retrospective, waarin de product owner, de scrum master en de leden van het product ontwikkelteam kijken naar de wijze waarop ze nu werken en een plan ontwikkelen om de wijze waarop ze werken in de komende sprint(s) verder te verbeteren. 

Elke van de genoemde onderdelen van Scrum is essentieel. Als je niet weet waar je naar toe gaat (lange termijn richting), hoe kun je dan verwachten dat je er ooit komt? Of zoals een Japans spreekwoord stelt: Visie zonder actie is dagdromen. Actie zonder visie is een nachtmerrie. Zonder sprint review en werkend product increment wordt het ophalen van feedback van de stakeholders erg lastig en wordt het lerend vermogen van het Scrum sterk beperkt. Back to basics betekent niet alleen terug naar de essentie van Scrum, maar ook terug naar de essentie van agility. Niet alleen de onderdelen van Scrum uitvoeren, maar ook weten waarom we deze uitvoeren.  

De basis van Scrum is niet moeilijk. De individuele onderdelen goed en effectief uitvoeren wel. De twee grootste uitdagingen die we bij Scrum tegen komen zijn de vragen “Hoe kom je tot een goed geprioriteerde en gebalanceerde product backlog?” en “Hoe zorg je dat product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd?”. In de navolgende blogpost gaan we dieper in op deze twee uitdagingen. 

Deze blogreeks wordt geschreven door Jurjen de Groot en Marco de Jong. Zij stellen zich graag even aan jullie voor:

Jurjen de Groot is een gepassioneerde Scrum en Agile expert consultant en trainer die gelooft in de eenvoud van de essentie van Agile. Door zijn unieke stijl van coaching laat hij organisaties zien dat een Agile adoptie van onder in de organisatie naar boven verspreid, erg haalbaar is.  

Marco de Jong is een ervaren en resultaatgerichte principal consultant op het gebied van Agile & Lean. Hij is een uitdagende coach en bevlogen trainer met een achtergrond in organisatie ontwikkeling, management en software development. Door zijn eigen stijl van coaching weet hij mensen te helpen het beste uit zichzelf en hun organisaties te halen.