Agile en “Product kennis”

Je hebt de stap gezet naar agile. Jouw ontwikkelaars “scrummen”, of het nu IT-ers, Marketeers of wat dan ook zijn. Fijn!

Maar hoe zorg je jouw scrum team niet alleen hard werkt, maar ook nuttig werkt?

Nou daar heb je de hele organisatie voor nodig. Je bent uiteindelijk agile met een reden. Je zoekt op een iteratieve, snellere manier een kwalitatief antwoord te geven op een onduidelijke, complexe markt.

Dus je moet ook ergens durven omgaan met onzekerheid bij de vraag “Wat wil mijn klant?”

En daar loopt het vaak fout! Om even om een oud artikel van CB Insights terug te vallen: in 2019 faalden maar liefst 42% van de startups omdat…er geen markt was voor wat ze ontwikkelden…pricing kwam pas op de vijfde plaats met 18%…Hoe dan?! Voor wie ben je dan al die tijd aan de slag gegaan?

Nu ben ik de laatste om te eisen dat je pas mag scrummen als je absolute zekerheid hebt. Die bestaat immers niet en analyse paralyse dient nergens toe. Dan ben je beter af met Waterfall te werken zoals vroeger, dan heb je tenminste nog een uitgebreide analyse en business case bedacht voordat je aan de slag ging met ontwikkeling. Maar het gaat allemaal over het nemen van beslissingen.

Een goeie Product Backlog is net gemaakt om beslissingen te kunnen nemen zonder 100% zekerheid. De taak van de Product Owner is hier dan ook cruciaal. Geen goede ideeën langs de vragende kant doet de hele machine sputteren.

Die Product Backlog is een schat aan informatie die je constant verrijkt met jouw klant. Je kan hiervoor terugvallen op verschillende bronnen.

• Workshops met jouw klanten
• Het Q&A team (zij weten wat er gevraagd en gezocht wordt, dus hier vind je ook verbeterpunten)
• Jouw helpdesk of customer support of account managers. Zij krijgen de vragen binnen zowel voor fixes als voor aanpassingen
• Specifieke vragen die binnenkomen bij Sales. Niet elk verzoek tot customisatie is welkom, maar je kan best goeie ideeën vinden hier.
• 

Als je die bouwstenen hebt begint het werk pas echt! Hoe ga je nou prioriteiten stellen?

Alles begint opnieuw met de vraag voor jouw organisatie: wat zijn de evaluatiecriteria?

• Je kan prioriseren op omzet. Uiteindelijk wil je dat jouw ontwikkeling rendeert, dus de feature met de meeste kans op omzet kan een goed startpunt zijn.
• Je kan ook inzetten op niches. Ben jij een sterke speler in een specifieke niche? Dan kan je prioriseren om wat die niche echt uniek maakt en zo steeds een stapje voor blijven.
• Als je wilt kijken naar opleverkansen kan je prioriteiten zetten op “complixiteit”. Wat is complexiteit? Nou bekijk het als het product van de moeilijkheid van ontwikkeling en de ingeschatte lanceringstijd. Hoe complexer, des te intensiever zal het worden, dus misschien neem je die grote complexe beestjes liever eerst onder de loep.
• Als je complexiteit kan inschatten, zal je ook kosten kunnen inschatten. Veel complexiteit kan veel tijd vragen of veel inspanning. Maar als een hoge kost samengaat met een korte ontwikkelingstijd kan je wel sneller je kosten terugverdienen.

Ongeacht welke methode je wilt gebruiken, het antwoord op die vragen ligt BUITEN jouw scrum team.

Praat dus met jouw klanten, hou nauw contact met andere teams, stem je af op de behoeften van jouw bedrijf, zorg dat de strategie transparant is en je duidelijk weet hoe je het beste bijdraagt met jouw product. Elk product dat je gaat ontwikkelen moet immers een duidelijk doel hebben, het moet bijdragen. En niemand weet beter wat die bijdrage gaat zijn, dan de mensen waarvoor je het zal ontwikkelen.

Volgende keer staan we stil bij hoe je nu van een Product Backlog kan overgaan tot het verfijnen en opleveren van jouw Increments!