Van Visie naar Product | blogreeks agile werken 3
door Strict op do 21 nov 2019
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.
Van Visie naar Product
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.
- Technologie (134)
- Nieuws (70)
- 5G (67)
- Continuïteit (64)
- Security & Privacy (57)
- Agility (35)
- Podcast (34)
- Wendbaarheid (31)
- Klantcase (18)
- Webinar (18)
- Blog (16)
- Innovatie (13)
- Mission Critical (13)
- Healthcare (12)
- Overheid (12)
- AI (11)
- Cloud (9)
- Medewerker interview (8)
- Smart City (7)
- Video (7)
- OOV (5)
- Vervoer (5)
- Projectmanagement (3)
- Duurzaamheid (2)
- december 2024 (4)
- november 2024 (9)
- oktober 2024 (9)
- september 2024 (10)
- augustus 2024 (6)
- juli 2024 (9)
- juni 2024 (6)
- mei 2024 (3)
- april 2024 (9)
- maart 2024 (11)
- februari 2024 (4)
- december 2023 (2)
- november 2023 (4)
- oktober 2023 (3)
- september 2023 (3)
- juli 2023 (4)
- juni 2023 (3)
- mei 2023 (6)
- april 2023 (2)
- maart 2023 (5)
- februari 2023 (1)
- januari 2023 (1)
- december 2022 (1)
- november 2022 (2)
- oktober 2022 (3)
- september 2022 (3)
- augustus 2022 (3)
- juli 2022 (8)
- juni 2022 (6)
- mei 2022 (4)
- april 2022 (5)
- maart 2022 (4)
- februari 2022 (5)
- januari 2022 (2)
- november 2021 (2)
- oktober 2021 (1)
- september 2021 (3)
- augustus 2021 (2)
- juli 2021 (1)
- juni 2021 (1)
- mei 2021 (1)
- april 2021 (3)
- maart 2021 (1)
- februari 2021 (1)
- november 2020 (1)
- augustus 2020 (1)
- juli 2020 (2)
- mei 2020 (2)
- april 2020 (4)
- maart 2020 (5)
- februari 2020 (3)
- januari 2020 (5)
- december 2019 (2)
- november 2019 (3)
- oktober 2019 (5)
- september 2019 (1)
- augustus 2019 (3)
- juli 2019 (2)
- juni 2019 (3)
- mei 2019 (2)
- april 2019 (4)
- maart 2019 (8)
- februari 2019 (6)
- januari 2019 (3)
- december 2018 (4)
- november 2018 (2)
- oktober 2018 (10)
- september 2018 (6)
- augustus 2018 (8)
- juli 2018 (2)
- juni 2018 (7)
- mei 2018 (3)
- maart 2018 (3)
- februari 2018 (3)
- januari 2018 (3)
- december 2017 (6)
- november 2017 (5)
- oktober 2017 (5)
- september 2017 (5)
- juli 2017 (1)
- juni 2017 (4)
- mei 2017 (1)
- maart 2017 (9)
- februari 2017 (1)
- januari 2017 (1)
- december 2016 (1)
- oktober 2016 (2)
- september 2016 (2)
- augustus 2016 (6)
- juli 2016 (1)
- juni 2016 (3)
- mei 2016 (2)
- april 2016 (3)
- maart 2016 (3)
- januari 2016 (1)
- december 2015 (1)
- november 2015 (2)
- oktober 2015 (1)
- september 2015 (2)
- augustus 2015 (1)
- juli 2015 (1)
- juni 2015 (2)
- mei 2015 (2)
- maart 2015 (2)
- februari 2015 (2)
- juni 2014 (1)