Stel, je bent een Product Owner in een Agile delivery team, klaar om aan de slag te gaan met je product. Om dat te kunnen doen, moet je je ontwikkelteam een doel geven en een lijst met dingen om aan te werken. Als je SCRUM als raamwerk gebruikt, noem je die lijst met dingen om aan te werken een Product Backlog. Uit de SCRUM-gids:

• De Product Backlog is een geordende lijst van alles waarvan bekend is dat het nodig is in het product. Het is de enige bron van vereisten voor alle wijzigingen die in het product worden aangebracht.
• De Product Backlog geeft een lijst van alle features, functies, vereisten, verbeteringen en fixes die de veranderingen vormen die in toekomstige releases in het product moeten worden aangebracht. Product Backlog items hebben de kenmerken van een beschrijving, volgorde, schatting en waarde. Product Backlog items bevatten vaak testbeschrijvingen die de volledigheid aantonen als ze "Done" zijn.

Oké, je moet dus beginnen met een backlog, prioriteiten stellen en dan de items met de hoogste prioriteit eerst bouwen. SCRUM - en Agile ontwikkeling in het algemeen - is zowel incrementeel als iteratief (zie hier of hier voor een goede uitleg van die termen). Laten we dit illustreren met een voorbeeld: als een klant een auto bestelt - en we gebruiken SCRUM om hem te implementeren - kunnen we itereren op het chassis en de auto incrementeel bouwen, zoals dit:

Als Product Owner(de rol die je inneemt als Product Manager) zit je echter met een paar vragen:

• Waar komt de backlog vandaan?
• Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost?
• Hoe weet ik zeker dat het ontwikkelteam mijn interpretatie van de behoefte ook daadwerkelijk levert?
• Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om aan te werken?

In deze blogpost proberen we die vragen geleidelijk te beantwoorden.

Focus op de onderliggende behoefte van de klant

Laten we beginnen met de tweede vraag op onze lijst: hoe kan ik er zeker van zijn dat het een behoefte van de eindgebruiker oplost? Henrik Kniberg wijst er terecht op:

We beginnen met dezelfde context - de klant heeft een auto besteld. Maar deze keer bouwen we niet gewoon een auto. In plaats daarvan richten we ons op de onderliggende behoefte die de klant vervuld wil zien. Blijkt dat zijn onderliggende behoefte is "Ik moet sneller van A naar B", en een auto is slechts één mogelijke oplossing daarvoor.

Vergeleken met ons vorige voorbeeld van een klant die een auto bestelt, zou het er nu zo uitzien:

Simpel gezegd betekent dit dat je eerst het echte probleem moet ontrafelen en naar eigen inzicht moet aanpassen. Het ontrafelen van het probleem is iteratief van aard: zolang je geen bevestiging krijgt dat je een echte behoefte aan het oplossen bent, moet je veranderen en aanpassen. Je presenteert de eindgebruiker een beste schatting van hoe een oplossing eruit zou kunnen zien. Zolang de gebruiker niet tevreden is, moet je dieper graven en met alternatieven komen. Uiteindelijk raak je de 'sweet spot' en krijg je de bevestiging dat je het probleem hebt begrepen. Deze bevestiging kan gebaseerd zijn op echte gebruiksgegevens, kwalitatieve inzichten of een combinatie van beide.

SCRUM geeft niet aan hoe je Henriks idee moet implementeren. Ik heb begrepen dat er een voorkeur is voor het ontwikkelen van software en het richten van de sprint op het eindigen met een increment. Dit betekent dat werkende software wordt gebruikt als artefact tijdens de iteratie om het probleem te definiëren. Het nadeel is echter dat het team reeds geïmplementeerde incrementen opnieuw moet bewerken, omdat ze moeten worden aangepast aan nieuwe inzichten. Ik heb de verspillingen van softwareontwikkeling gecontroleerd en de potentiële verspillingen geïdentificeerd:

• Schatting niet mogelijk door slechte analyse/informatieverzameling (Partially Done Work).
• Technische complexiteit niet goed geanalyseerd (Partially Done Work), omdat het geen zin heeft om dit tijdens een iteratie te doen.
• Verkeerde keuze van technologie of oplossing (Defects), omdat de niet-functionele eisen een bewegend doel zijn.
• Herontwerpen vanwege gemiste requirements (Defecten).

Dit zijn nog steeds aandachtspunten die kunnen worden opgelost door een goede productontdekkingsstap.

Laten we eerst nog eens kijken naar de vragen waar een Product Owner mee kan zitten en aangeven welke we hebben opgelost:

• Waar komt deze backlog vandaan?
• Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost? ✅
  
  • We beginnen met een idee en itereren tot we een oplossing vinden die een behoefte vervult. Dit blijven we doen tot we een bevestiging krijgen.
• Hoe kan ik er zeker van zijn dat het ontwikkelteam mijn interpretatie van de behoefte ook daadwerkelijk levert?
• Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om mee te werken? ❌
  
  • Dit maakt het probleem groter: het ontwikkelteam moet nu (ten minste wat) meer werk verzetten om alle wijzigingen te verdoezelen.

Ontdek de behoeften van je gebruiker

Om de potentiële verspilling in het voorbeeld van Henrik te elimineren, moet je het iteratieve deel (uitzoeken wat de gebruiker nodig heeft) en het bouwen van de software (een oplossing voor het probleem maken) opsplitsen.Uitzoeken wat de gebruiker nodig heeft, houdt een zogenaamde ontdekkingsstap in.

Marty Cagan, de "meest invloedrijke persoon in de productruimte",is het hiermee eens:

In Henriks voorbeeld is het team bezig om tegelijkertijd te bepalen wat het juiste product is om te bouwen en om dat product te bouwen. En ze hebben één belangrijk hulpmiddel tot hun beschikking om dat te doen: de ingenieurs. Dus wat je ziet is een progressief ontwikkeld product, met een belangrijke nadruk op iets dat we bij elke iteratie kunnen testen op echte gebruikers.

Henrik benadrukt dat ze bouwen om te leren, maar ze doen dit met het enige gereedschap dat ze denken te hebben: ingenieurs die code schrijven. Als je goed leest, vermeldt Henrik dat de ingenieurs eigenlijk geen producten hoeven te bouwen - ze zouden prototypes kunnen bouwen, maar bij de meeste teams die ik ontmoet, gaat dit punt verloren omdat ze niet begrijpen dat er veel vormen van prototypes zijn, waarvan de meeste niet bedoeld zijn om door ingenieurs te worden gemaakt.

Dat klopt: het schrijven van software kan een goede oplossing zijn om erachter te komen wat de gebruiker wil, maar meestal is het de duurste manier om er te komen.

Met een ontdekkingsstap kun je je richten op de doelstellingen van een product: is het waardevol, bruikbaar, haalbaar en levensvatbaar? Deze stap is meestal iteratief. Het eindresultaat is een duidelijke probleemdefinitie en dus een mogelijke oplossing voor dat probleem; een oplossing met een hoge waarschijnlijkheid om de behoefte van een gebruiker op te lossen. Omdat je een ontdekkingsstap hebt genomen, betekent dit dat je het echte probleem kunt beschrijven aan het engineeringteam. Je kunt het probleem ook gedetailleerder beschrijven en ook beschrijven wat voor eigenschappen je verwacht van de eindoplossing, bijvoorbeeld een fitnessfunctie die de oplossing in context plaatst. De ontwikkelteams zoeken dan uit hoe ze die oplossing moeten bouwen. Dit is de opleveringsstap en deze is meestal incrementeel.

Productontdekkingsspoor versus leveringsspoor

Bij de productontdekkings- en leveringsstappen zijn er twee sporen die het team moet overwegen: een productontdekkingsspoor en een leveringsspoor.

Laten we de vragen van de Product Owner een derde keer opnieuw bekijken en aangeven welke we hebben opgelost:

• Waar komt deze backlog vandaan?
• Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost? ✅ ✅
  • We beginnen met een idee en itereren totdat we een oplossing hebben gevonden die een behoefte vervult.
  • We zouden echt meer tijd moeten besteden aan onze eindgebruikers om hun probleem echt te begrijpen.
  • We moeten proberen dit zo snel mogelijk te doen, zodat de engineeringtijd niet opraakt.
• Hoe kan ik er zeker van zijn dat het ontwikkelteam mijn interpretatie van de behoefte ook echt levert?
  • Wat betreft de probleemomschrijving kan ik meer details en context geven.
• Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om mee te werken?
  • De engineers weten echt wel dat het een auto gaat worden voordat ze een geschikte architectuur kunnen bedenken die geschikt is voor de taak, en ze kunnen er in feite voor kiezen om deze architectuur te implementeren met een andere opleveringsstrategie dan een die ontworpen is om snel te leren.
  • Naarmate de risico's tijdens het ontdekken worden aangepakt en het noodzakelijke opleverwerk duidelijk wordt, gaat dat opleverwerk veel sneller dan anders het geval zou zijn.

Dubbel spoor: product ontdekken en opleveren gebeuren tegelijkertijd

Ontdekkingswerk richt zich op snel leren en valideren. Maar hoe koppel je dat aan het opleveringswerk? Als een project begint, doe je misschien eerst discovery en laat je - iets later - het engineeringteam beginnen.

Het wordt dan zo:

Dat lijkt veel op Waterfall! Maar zo hoeft het niet te zijn. Jeff Patton, een veteraan Product Manager en schrijver van het boek User Story Mapping, zegt dat het allemaal tegelijk gebeurt (Dual Track). In plaats van een waterval krijgen we een loop. Een lus voor ontdekkend leren ziet er ongeveer zo uit:

Het begint met het beschrijven van

• wat we denken dat het probleem is dat we proberen op te lossen en voor wie,
• de oplossing om het probleem op te lossen,
• en hoe we het succes ervan meten.

Productontdekkingssessies lopen als volgt in elkaar over:

Ontdekkingswerk maakt gebruik van onregelmatige cycli. Het is 'lean' in de zin dat we proberen de ontdekkingscyclus zo kort mogelijk te maken. Ontdekideeën muteren en worden vaak verlaten, wat de beste stap is naar meer doelbewuste ontwikkelingscycli.

Takeaway

Om potentiële risico's te elimineren, moet je je bewust zijn van zowel de ontdekkingsstap als de opleveringsstap. De ontdekkingsstap richt zich op de doelstellingen van een product: waarde, bruikbaarheid, haalbaarheid en levensvatbaarheid en is meestal iteratief. De opleveringsstap richt zich op hoe je een product bouwt en is meestal incrementeel. Hoewel de stappen gescheiden zijn, vinden de sporen tegelijkertijd plaats, wat we Dual Track noemen.

Het artikel van Jeff Patton over Dual Track noemt ook een paar belangrijke punten.

• Deze twee sporen zijn twee soorten werk die door hetzelfde team worden uitgevoerd.
  
  • Discovery moet regelmatig met het team controleren op haalbaarheid, juiste implementatie en technische beperkingen die van invloed zijn op de ontwerpbeslissing.
  • Delivery gebruikt inzichten uit discovery tijdens de ontwikkeling.
• Discovery richt zich eerst op de meest riskante aannames, d.w.z. gebruikersproblemen waarvan we weinig vertrouwen hebben dat ze een echte gebruikersbehoefte oplossen (of de behoefte is onbekend).
• Oplevering richt zich op oplossingen waarvan we een hoog vertrouwen hebben dat ze het probleem van een gebruiker oplossen.
  
  • Het vertrouwen kan voortkomen uit gevalideerd leren tijdens het ontdekken.
  • Of we beginnen - bijvoorbeeld aan het begin van een cyclus - met backlog items waarvan we denken dat er geen discovery nodig is, zoals technisch werk of features waarvan we al een hoog vertrouwen hebben dat ze een gebruikersprobleem oplossen.

De twee sporen worden parallel uitgevoerd:

• Discovery / Iteration: focus op de meest riskante aannames (problemen waarvan we de minste kennis hebben) en probeer deze met zo min mogelijk inspanning te definiëren.
• Oplevering / Increment: focus op een goed gedefinieerde oplossing (we hebben een hoog vertrouwen dat de eindgebruiker het nodig heeft) en pak de oplossingen met de hoogste waarde het eerst aan.

Het spoor stopt niet zodra je een probleem hebt ontdekt om op te lossen. Het volgende probleem loert al om de hoek. In ons voorbeeld met de klant die een auto bestelt ("Ik moet sneller van A naar B"), zouden we ook kunnen denken dat de gebruiker onderdak nodig heeft, wat kan variëren van een eenvoudige hut tot een kasteel.

Een laatste opmerking: deze blogpost begon met SCRUM als het raamwerk voor oplevering, maar de methodologie doet er niet echt toe: het zou Kanban, Crystal XP en zelfs Waterval kunnen zijn, zolang het team maar in staat is om gelijke tred te houden met de twee sporen. Maar omdat het ontdekkingsgedeelte gericht is op snelleren , past een Agile methodologienatuurlijk beter.

Resterende vragen

Laten we de vragen van de Product Owner nog een laatste keer bekijken en aangeven welke nu zijn opgelost.

• Waar komt deze backlog vandaan? ✅
  • De backlog komt voort uit aannames die tijdens discovery zijn gevalideerd.
  • Er is echter een nieuwe vraag: hoe identificeren we de lijst met veronderstellingen waarop we ons moeten richten? Waar komt de lijst van Opportunities vandaan? ❓
    
• Hoe weet ik zeker dat het een behoefte van de eindgebruiker oplost? ✅✅✅✅
  • We beginnen met een idee en itereren tot we een oplossing hebben gevonden die een behoefte vervult.
  • Ik zou echt meer tijd moeten besteden aan mijn eindgebruikers en hun probleem echt moeten begrijpen.
  • Ik zou moeten proberen om dit zo snel mogelijk te doen, zodat de engineering niet zonder werk komt te zitten.
  • Doe dit parallel, met het hele team.
• Hoe kan ik er zeker van zijn dat het ontwikkelteam mijn interpretatie van de vereisten ook echt levert? ✅
  
  • In termen van probleemomschrijving kan ik meer details en context geven.
  • Betrek (ten minste een deel) van je engineeringteam bij discovery. Op deze manier komen ze in contact met de echte eindgebruiker en krijgen ze een beter begrip van de echte wereld van de gebruiker.
• Hoe kan ik er zeker van zijn dat ik me aanpas aan veranderingen en mijn architect toch een duidelijke (minder evoluerende) set parameters geef om mee te werken? ✅
  • De ingenieurs weten echt wel dat het een auto wordt voordat ze een geschikte architectuur kunnen bedenken. Ze kunnen er zelfs voor kiezen om deze architectuur te implementeren met een andere leveringsstrategie dan een die ontworpen is om snel te leren.
  • De risico's worden in discovery aangepakt en het noodzakelijke opleverwerk wordt duidelijk. Het opleveringswerk kan nu veel sneller gaan dan anders het geval zou zijn.