In de voorgaande blogpost “Back to Basics” hebben we geconstateerd dat Scrum tien essentiële onderdelen bevat om op teamniveau de basis te leggen voor de transformatie naar een lerende organisatie. Daarbij zijn we twee grote uitdagingen tegen gekomen: “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 deze blogpost gaan we dieper in op de eerste uitdaging: “Hoe kom je van een visie tot een goed geprioriteerde en gebalanceerde product backlog?”
Goed product ownerschap is van essentieel belang om tot een goed onderbouwde, op waarde gesorteerde en incrementeel uitleverbare product backlog te komen. Ondanks het feit dat de Scrum guide een goed beeld geeft van de opzet en werking van een product backlog, wordt aan de wijze waarop deze backlog tot stand komt nauwelijks aandacht besteed. Veel product owners lopen dan ook met de vraag rond wat er op de product backlog moet komen te staan, hoe ver deze uitgewerkt moet worden, wat het juist balanceren van een backlog betekent, hoe de waarde en daarmee de prioriteit van product backlog items moet worden bepaald en hoe je overzicht houdt over de complexiteit die product ontwikkeling met zich mee brengt.
Een goed onderbouwde, op waarde gesorteerde en incrementeel uitleverbare product backlog is niet het begin van Scrum maar het eindresultaat van een voortdurend en iteratief proces van product verkenning en ontwikkeling. Dit proces begint bij met neerzetten van een heldere, duidelijke visie voor het te realiseren product of doel, waarna in verschillende stappen en activiteiten de mate van detaillering, prioriteitstelling en waarde worden uitgewerkt op basis van de ervaringen die met het product in de praktijk wordt opgedaan. Met het ontbreken van een duidelijke visie is de kans op een stuurloos Scrum team erg groot, er is immers geen stip op de horizon waar het team zich op kan richten. Helaas komen we in de praktijk regelmatig Scrum teams tegen zonder visie, een onbekende visie of een zeer onduidelijke visie.
De grondlegger van Scrum Ken Schwaber gaat in zijn boek “Agile Project Management with Scrum “dieper in over het belang van de product owner om een heldere visie te definiëren voor het product. Deze visie reflecteert de motieven van het project en het gewenste eindresultaat. De visie is een beknopte beschrijving van de essentie van het product en de achterliggende doelen die moeten worden bereikt, maar aan de andere kant nog steeds algemeen genoeg om niet beperkend te zijn voor de creativiteit.
Een heldere visie haalt een groot deel van de onzekerheid weg dat we “maar een beetje in het wilde weg experimenteren”, een argument dat nog te vaak op managementniveau naar voren wordt gebracht wanneer over Agile werkwijzen wordt gesproken. Een heldere visie zorgt namelijk voor continue alignment tussen de resultaten van het team tot nu toe en de volgende stappen die genomen moeten worden om de visie te realiseren. Hoe scherper de visie, hoe duidelijker de voortgang richting die visie kan worden bereikt.
De Agile Product Management consultant Roman Pichler licht in zijn boek “Agile Product Management with Scrum” toe dat een visie een duidelijke beschrijving geeft wie de klanten zijn, wat zij nodig hebben en op welke wijze aan hun wensen kan worden voldaan. Het is de rol van de product owner om te borgen dat de visie voor het product gedurende de gehele levenscyclus wordt nagestreefd. De visie is daarmee ook een cruciaal onderdeel van de onderliggende business case, waarbij de realisatie van de business case gedurende de ontwikkelingscyclus continu wordt gemonitord.
Om een visie goed te kunnen uitdragen, stelt Roman Pichler het gebruik van een vision board voor. Dit instrument ondersteunt je in het beschrijven, visualiseren en valideren van de product visie en strategy. Het bestaat naast een tekstuele beschrijving van de visie uit een overzicht van de belangrijkste doelgroepen, de gebruikerswensen, de essentiële producteigenschappen en de te realiseren bedrijfsdoelstellingen. Door deze structuur is het mogelijk dwarsverbanden te onderkennen (welke doelgroepen hebben de grootste invloed op het bereiken van de gewenste bedrijfsdoelstellingen of welke producteigenschappen missen we nog om aan de belangrijkste gebruikerswensen te voldoen).
Het vision board is daarmee een uitstekend middel om de opgestelde strategie te communiceren met alle stakeholders (zowel vanuit de business als vanuit product ontwikkeling). Vanuit een vision board kunnen verschillende producten of bedrijfsmodellen worden afgeleid. Voor productontwikkeling wordt veelal gebruik gemaakt van een instrument als een product canvas, terwijl voor een dienstontwikkeling meer gebruik wordt gemaakt van de business model canvas.
Zodra een visie concreet begint te worden en de contouren van een product zichtbaar worden bestaat veelal de neiging om het product met teveel diepgang te gaan beschrijven. Immers, hoe concreter een product wordt uitgewerkt, hoe meer direct deze de huidige behoefte van de belanghebbenden adresseert. Het grote gevaar hierbij is dat we aanname op aanname doen doordat er geen feedback komt vanuit het actuele gebruik van het product. En hoe meer is beschreven, hoe minder wordt geëxperimenteerd en hoe groter de barrière wordt om überhaupt van de (reeds met veel detail beschreven) koers af te wijken. Kortom, overmatige detaillering is strijdig met een wendbare productontwikkeling.
Een product canvas geeft een overzicht van het te ontwikkelen product en is bedoelt als communicatiemiddel richting alle betrokken. Het toont op hoog niveau de customer journeys die de belangrijkste gebruikers van het product doorlopen, welke logische activiteiten daarin te onderkennen zijn, welke ontwerp afwegingen er zijn gemaakt en met welke beperkingen rekening moet worden gehouden. Een product canvas helpt om grip te krijgen op de complexiteit van een groot product, en effectief gesprekken te kunnen voeren met diverse belanghebbenden van het product.
Een andere uitdaging van het plannen en werken met meerdere iteraties van een product is om te komen tot logische releases. Agile frameworks zoals Scrum hebben als eis dat een product aan het einde van een iteratie (in Scrum een Sprint genoemd) in uitleverbare conditie moet zijn, oftewel het team hoeft geen werk meer te verzetten wanneer besloten wordt om het product uit te leveren. Maar technisch uitleverbaar is niet synoniem met logisch of functioneel uitleverbaar. Hierbij wordt het de vraag welke combinatie van functionaliteit leidt tot een product waarvan het zinnig is om deze uit te leveren. Een hulpmiddel als een (user) story map geeft inzicht in de functionaliteit van het systeem, maakt eventuele functionele gaten zichtbaar, en ondersteunt het plannen van holistische releases die waarde leveren aan de gebruikers en de business met elke release van het systeem. Door het gebruiken van een hulpmiddel als een (user) story map is het vormen (of bijwerken) van een product backlog een stuk eenvoudiger geworden. Immers, de gedetailleerde stories van de huidige release kunnen hoog op de product backlog geprioriteerd worden opgenomen, terwijl de overige features / epics op een lager niveau qua prioriteit kunnen worden weergegeven.
Van hulpmiddelen naar processtappen
Kortom, een Agile framework als Scrum begint met een goede visie, een goede product backlog is het resultaat. Scrum laat je vrij hoe je vanaf een visie tot de product backlog moet komen, hiervoor zijn verschillende routes te bewandelen. Instrumenten als een vision board en product canvas blijken in de praktijk goed te helpen om de omgeving in kaart te brengen. Een story map is een uitstekend instrument om logische, waardevolle releases te definiëren en op te leveren. Door het gebruiken van dergelijke hulpmiddelen is het een stuk eenvoudiger om een product backlog goed op te zetten.
Een vision board, product canvas en story map zijn echter slechts hulpmiddelen die worden gebruikt om het proces ondersteunt om vanuit visie naar een goed opgebouwde product backlog te komen. Als we op een andere manier naar dit proces kijken en de focus leggen op de individuen en hun interacties, dan zien we een aantal verschillende fasen ontstaan die cyclisch wordt doorlopen. Immers, zodra we op basis van een visie bezig gaan om aspecten als wensen, behoeften en ideeën te concretiseren zijn we bezig met het definiëren van aspecten om de visie te realiseren. De meeste simpele vorm hiervoor is het vastleggen van de behoefte in grote, omvangrijke product backlog items (veelal epics genoemd) die de behoefte van bijvoorbeeld de drie grootste doelgroepen dekt.
Wanneer we schaarse capaciteit gaan gebruiken om omvangrijke product backlog items te realiseren, is het van belang dat we continu blijven werken aan de omvangrijke product backlog items die op dat moment de hoogst mogelijk waarde leveren. Om dit reden is het van belang om continu de product backlog items te blijven prioriteren. Het proces van prioriteren kan hierbij worden ondersteunt met hulpmiddelen als een vision board (bijv welke doelgroep of bedrijfsdoelstelling is het meest belangrijk) of product canvas (welke customer journey heeft de hoogste impact). Maar de product owner kan ook prioriteren op basis de gesprekken die hij of zij voert met de belangrijkste stakeholders.
Omvangrijke product backlog items kunnen door hun omvang niet kortcyclisch worden gerealiseerd. Dus wanneer we aan de slag willen gaan met de omvangrijke product backlog item die de hoog mogelijke waarde levert, moeten we deze eerst opdelen (slicen) waarbij een deel van de epics in kleine delen wordt opgebroken. Dus welk aspect of onderdeel van de omvangrijke product backlog item levert wederom de meeste waarde. Door het slicen van items worden omvangrijke items minder omvangrijk en ontstaan er kleinere items op de backlog die door deze actie worden gedefinieerd en opnieuw kunnen worden geprioriteerd. Het proces van het definiëren, prioriteren en slicen is daarmee een continu proces wat ook wel product backlog management wordt genoemd.
Bij het slicen van product backlog items is het van essentieel belang dat elk nieuw onderdeel afzonderlijk ook nog steeds waarde blijft leveren. De vraag blijft bij elk nieuw onderdeel dan ook altijd of het logisch is wanneer deze afzonderlijk aan de gebruiker ter beschikking wordt gesteld en of hij / zij daar dan ook blij van wordt. Dit voorkomt dat producten op een technische wijze worden gesliced en we vooral voor een continue stroom van waardevolle software leveren aan de klant. Waardevolle software waar we ook waardevolle feedback op kunnen krijgen. Het is bijvoorbeeld eenvoudiger om vanuit een gebruiker feedback te krijgen wanneer het gehele proces wordt ondersteunt dan wel afgehandeld voor een heel klein deel van de uiteindelijke doelgroep, dan wanneer hij achtereenvolgens feedback moet geven op het database ontwerp, de messaging structuur en de user interface.
De geprioriteerde items gaan we vervolgens uitzetten in een zich continu ontwikkelende product planning. Deze activiteit kan worden ondersteunt met hulpmiddelen als een rainbow map of story map om te borgen dat we feedbacklussen creëren waarmee de huidige staat van het increment zo snel en goed mogelijk kan worden getoetst bij de eindgebruikers en stakeholders. Het resultaat van deze activiteit resulteert in een goed gebalanceerde en geprioriteerde product backlog.
Nu een beeld is ontstaan welke aspecten en hulpmiddelen kunnen worden gebruikt om te komen van een visie tot een goed gebalanceerde en geprioriteerde product backlog, kunnen we deze aspecten toevoegen aan het eerder gepresenteerde model van plan, execute, inspect & adapt. Dit resulteert in de volgende representatie van het model.
Deze stappen vinden continu en cyclisch plaats in een voldoende ritme dat het ontwikkelteam elke sprint kan werken aan die onderdelen van de visie die op dat moment de meeste toegevoegde waarde levert. De volgende uitdaging waar we dan tegenaan lopen is het omgaan met een continue stroom van nieuwe increments die aan de gebruikers en stakeholders ter beschikking wordt gesteld. Want je kunt nog zo’n snel en wendbaar plan en execute proces hebben, dit heeft alleen zioordenn wanneer alle inspanning ook snel ter beschikking wordt gesteld aan de gebruikers en stakeholders. In de navolgende blogpost gaan we dieper in op deze uitdaging: “Hoe zorg je dat product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd?”
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.
