Onbewust onbekwaam
“Dat weet ik niet. We doen het al jaren op deze manier en dat bevalt prima”, antwoordde de gebruiker op de vraag hoe hij geholpen kan worden in het efficiënter uitvoeren van zijn taken. Het is één van de kenmerkende citaten die wij horen bij een bezoek aan business owners en eindgebruikers om requirements op te halen voor de ontwikkelingen die gaande zijn binnen de organisatie.
“Stakeholders zijn in dit geval onbewust onbekwaam”
De hierboven beschreven ‘impediment’ zien wij in onze rol als Product Owner gelukkig niet altijd, maar wel geregeld terugkomen in onze dagelijkse praktijk. Stakeholders willen wel meewerken aan de beoogde veranderingen en kunnen zich vaak wel vinden in de (nieuwe) visie van het bedrijf. Echter vinden zij het vooral lastig vinden om aan te geven wat precies de problemen zijn waar zij tegenaan lopen, hoe hun processen verbeterd kunnen worden, hoe hun werkomgeving eruit moet komen te zien en welke functionaliteiten daarvoor nodig zijn. Sommige van deze stakeholders doen letterlijk al tientallen jaren hun werk op (bijna) dezelfde manier en zien de noodzaak niet om veranderingen door te voeren. Daarbovenop komt dat zij totaal niet bezig zijn met het digitaliseren van hun werkomgeving. Zij werken bijvoorbeeld in een fysieke omgeving en realiseren zich niet dat IT hen kan helpen in het efficiënter werken. Stakeholders zijn in dit geval onbewust onbekwaam.
Als Product Owner heb je te dealen met bovenstaande situatie. Jij bent immers verantwoordelijk voor het opstellen van user stories, voor het creëren van een Product Backlog, voor het bepalen van de prioriteiten en de oplevering van waardevolle software. Helaas geeft de theorie over Agile en Scrum weinig houvast over hoe een Product Owner om moet gaan met de onbewuste onbekwaamheid van business owners en eindgebruikers. De Scrum Guide leert ons dat de Scrum Master verantwoordelijk is voor het optimaal implementeren van Scrum. Hij of zij zou de stakeholders op de hoogte moeten brengen van hun rol in het project en hen in staat moeten stellen om een actieve bijdrage te leveren. In de praktijk zien wij echter dat de Scrum Master zich, zeker in het begin van het project, vooral richt op (de samenwerking tussen) de Product Owner en het development team en minder bezig is met de stakeholders van het product. In de ideale situatie wordt de Product Owner door de verschillende stakeholders benaderd voor het toevoegen van functionaliteiten, maar tegenovergestelde situaties komen absoluut ook voor. In dat geval is het aan de Product Owners om proactief requirements op te halen in de organisatie en dat vraagt om een hele andere benadering. Hoe kunnen Product Owners het eerder genoemde ‘impediment’ tackelen? Hieronder een aantal benaderingen die kunnen helpen.
Neem stakeholders bij de hand
Wij merken in de praktijk dat het goed werkt om de business owners en eindgebruikers bij de hand te nemen in de zoektocht naar digitale transformatie binnen de organisatie. Laat zien welke (IT-)mogelijkheden gangbaar zijn in de organisatie, met welke nieuwe technieken en methoden de organisatie aan het experimenteren is, waarom het van belang is om ook op zijn of haar afdeling veranderingen door te voeren, dat verandering alledaags is en dat verandering absoluut niet nadelig hoeft uit te pakken. Door stakeholders te laten wennen aan de ideeën die leven en de veranderingen die eraan zitten te komen, zullen zij minder in de weerstand schieten en zelf ook gaan nadenken welke functionaliteiten kunnen bijdragen aan de (nieuwe) doelstellingen.
Laat requirements evolueren
Verwacht niet dat alle requirements bij de eerste kennismaking helder zijn. Integendeel: het kost tijd om het vertrouwen te winnen van je stakeholders en iemand enthousiast te maken voor veranderingen. De gedachte achter agile werken is dat bestaande requirements zich in de loop der tijd ontwikkelen, dat nieuwe requirements ontstaan en irrelevante requirements verdwijnen. Probeer als Product Owner op deze manier ook je stakeholders te benaderen. Het geeft niet dat zij andere inzichten krijgen en dat requirements zich daarop aanpassen. Deze evolueren in tijd. Probeer stakeholders te helpen om zich kwetsbaar op te kunnen en willen stellen. Zoals het Agile Manifesto aangeeft: “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” Geef de business owners en eindgebruikers het vertrouwen dat je als Product Owner de aangedragen requirements serieus neemt en dat veranderingen stap voor stap doorgevoerd worden.
“Er is geen ‘heilige graal’ als het aankomt op het proactief ophalen van requirements.”
Start klein en kom zo tot de kern
Er is geen ‘heilige graal’ als het aankomt op het proactief ophalen van requirements. Enkele veel gebruikte methoden zijn het organiseren van workshops, brainstormsessies, één-op-één gesprekken, interviews, story mapping en het analyseren en modelleren van processen. Ook het starten met een Minimum Viable Product (MVP) is wat ons betreft een uitstekende manier om requirements boven tafel te krijgen. Door vroeg te starten met een MVP krijgen stakeholders het toekomstig product onder ogen en kunnen ze ‘spelen’ met de resultaten. Dit triggert hen vaak direct tot aanvullende requirements (“Oh! Als het dit kan, dan zou het ook dat moet kunnen”). Daarnaast is het slim om stakeholders de acceptatiecriteria op te laten stellen. Op deze manier stimuleer je hen om na te denken over wat het systeem moet kunnen en maak je concreet wanneer het goed (genoeg) is.
Tot slot: ga er als Product Owner niet vanuit dat requirements wel naar je toekomen met de gedachte dat “de business immers een belang heeft bij de ontwikkelingen”. Door actief je stakeholders op te zoeken en hen mee te nemen in de zoektocht naar de ideale oplossing, is het mogelijk om producten neer te zetten die veel waarde toevoegen aan de organisatie. Na verloop van tijd zul je zien dat stakeholders wel steeds beter weten wat ze nodig hebben: dan komen die user stories vanzelf!
Over de auteurs
Jelle Roo en Michiel Beskers werken beiden bij Capgemini en hebben jarenlange ervaring met agile werken in verschillende functies, zoals Product Owner, Scrum Master of agile business/informatie analist. In de reeks ‘Het dagboek van een agilist’ schetsen zij waarnemingen uit hun dagelijkse praktijk die raakvlakken hebben met zowel een digitale transformatie als een transformatie naar een Agile en Scrum manier van werken.
