Tools voor agile product management van Roman Pichler

Onlangs had het team van Lucidspark de kans om samen te werken met Roman Pichler én twee van zijn populairste tools, het product vision board en de GO productroadmap, te recreëren als sjablonen voor Lucidspark.

Voordat ik deze sjablonen laat zien, wil ik graag dat je iets meer weet over Roman en de enorme impact die hij heeft gehad op de agile-community.

Roman Pichler en agile scrum

In de begindagen van agile werd de scrum-community verankerd door een kleine groep toegewijde, gepassioneerde mensen. Zo heb ik Roman voor het eerst ontmoet—we waren lid van dezelfde professionele community en waren soms sprekers of begeleiders bij evenementen in de sector. De scrum-community was blij dat Roman zijn visie en kennis van productmanagement kon delen.

Roman was een van de eerste scrum-experts bij Siemens, en heeft vanuit die ervaring bijgedragen aan onze community. Roman zorgde voor nieuwe inzichten over de rol van een scrum product owner, een rol die op dat moment ondervertegenwoordigd was. Dit is de belangrijkste rol die de kloof dicht tussen de zakelijke kant (aanvrager) en de uitvoerende kant van de productontwikkeling. 

Romans gedachten hebben onze gemeenschap geholpen om de processen, pijnpunten en het dagelijkse werk van de product owner stakeholder beter te begrijpen. Met dit inzicht creëerden we programma's en middelen voor deze belangrijke scrum-rol.

Het duurde niet lang voordat Roman zijn reputatie als expert en visionair leider op het gebied van agile wist op te bouwen. Hij begon een aantal van zijn tools uit te werken (zoals het product vision board en de GO productroadmap) en deelde zijn inzichten met de agile- en product management communities. De hele agile-community leerde Roman kennen in 2010, toen hij Agile Product Management with Scrum: Creating Products that Customers Love publiceerde.

De kloof tussen scrum en product management dichten

Om deze bijdragen aan de agile-community te begrijpen, is het belangrijk om een stap terug te zetten en de context te verkennen rond de veranderingen op de werkplek waarvoor agile-experts zoals Roman Pichler altijd hebben gepleit. 

De bedoeling van agile was om de kloof te dichten tussen de zakelijke kant van bedrijven en de uitvoerende kant van diezelfde bedrijven. Simpel gezegd: voor de komst van agile waren bedrijven routinematig bezig met het managen van de output in plaats van hun resultaten, met een bijzondere focus op efficiëntie. 

De metafoor van een estafette illustreert hoe het werk van de technologen in goede banen werd geleid. De managers concentreerden zich op de lopers en overwogen problemen zoals: waren alle lopers op de baan? Welke lopers liepen voorop, welke hielden gelijke tred, en welke bleven achter? Hoe kunnen de prestaties van de lopers worden geoptimaliseerd en de output verhoogd? 

Terwijl we dit alles aan het managen waren verloren we het doel uit het oog: het stokje over de eindstreep krijgen. We hebben met andere woorden resultaten opgeofferd aan output.

Dit productontwikkelingsproces ging gepaard met overdrachten, formele documenten, review gates en goedkeuringsprocessen. Terwijl we ons best deden om met zoveel precisie te communiceren, werd het moeilijk om de belangrijkste factoren voor de ontwikkeling op elkaar af te stemmen. 

Het resultaat van al deze documentatie en evaluatie? Een product dat goed ontworpen en gespecificeerd is, los van de personen die het zouden bouwen, en vele lange maanden voordat het daadwerkelijke ontwikkelingswerk zou beginnen.  

Product owners en agile werken

Het Agile Manifesto en de bijbehorende principes zorgden voor een hoognodige interventie in dit omslachtige productontwikkelingsproces en vestigden de aandacht op het belang van:

• Samenwerken met en voldoen aan de wensen van de klant 
• Experimenteren met een werkend product in ontwikkeling, tegenover onnodig uitgebreide documentatie voordat je aan de slag gaat
• De ontwikkelaar werkt dagelijks samen met je medewerkers
• Reageren op onvermijdelijke veranderingen in plaats van vastberaden door te gaan volgens het oorspronkelijke plan 

Een agile-team onder leiding van een toegewijde product owner heeft vooraf geen volledig uitgewerkt ontwerp en een gedocumenteerd voorspellend projectplan nodig. In plaats daarvan werken deze teams met een herhalend, incrementeel raamwerk waarbij de planning en uitvoering plaatsvinden in een reeks korte iteraties (sprints). 

In dit model gaan planningsgesprekken slechts enkele dagen vooraf aan het eigenlijke werk. De aanwezigheid van een product owner zorgt voor een onderlinge afstemming waarbij teams deelnemen aan regelmatige contactmomenten om te zien of ze elkaar begrijpen en om feedback te krijgen over hoe ze het werk uitvoeren. Roman en andere bijdragers hebben een belangrijke rol gespeeld bij het opstellen van de leerdoelstellingen voor de eerste opleidingsprogramma's voor scrum product owners. Deze programma's hebben een beter inzicht opgeleverd over hoe deze nieuwe rol kan worden vervuld.

In het begin was het moeilijk om het bedrijf te vragen of iemand de rol van product owner op zich kon nemen, omdat mensen met een bedrijfsfunctie gewend waren om zich afzijdig te houden en niets te verliezen. Maar door de invloed van mensen als Roman werd de meerwaarde van een toegewijde product owner al snel duidelijk.

Visuele product management tools voor product owners

Als onderdeel van zijn toolkit voor product owners en productmanagers creëerde Roman het product vision board en de GO productroadmap. Deze visuals bieden een eenvoudig kader om een samenwerkingsproces mogelijk te maken ter ondersteuning van de belangrijkste resultaten.

Het product vision board

Het product vision board helpt bij de vroege productontwikkeling door teamleden te betrekken bij belangrijke vragen binnen de vijf categorieën: visie, doelgroep, behoeften, product en bedrijfsdoelen.

Visie

• Wat is je doel bij het maken van het product?
• Welke positieve veranderingen zou het teweeg kunnen brengen?

Doelgroep

• Voor welke markt of welk marktsegment is het product bestemd?
• Wie zijn de potentiële klanten en gebruikers?

Behoeften

• Welk probleem lost het product op?
• Welk voordeel levert het op?

Product

• Wat voor product is het?
• Wat maakt het zo bijzonder?
• Is het haalbaar om het product te ontwikkelen?

Bedrijfsdoelen

• Welke voordelen zal het product voor het bedrijf opleveren?
• Wat zijn de bedrijfsdoelen?

Iedere opmerking en ieder inzicht dat aan het bord wordt toegevoegd, maakt de visie van een team op hun product duidelijker. Dit Lucidspark-sjabloon stimuleert onderzoek en iteratie, en benadrukt het belang van een duidelijk inzicht in wat er moet worden gecreëerd, in plaats van belangrijke beslissingen te baseren op je intuïtie.

Bovendien is het product vision board gericht op de eindgebruiker van elk product. De richtvragen van het bord helpen de teams om zich in te leven in de vragen, behoeften en verwachtingen van de gebruikers. Kortom, het proces van een product vision board leidt tot een grondig inzicht in de context en de doelstellingen bij het nemen van beslissingen over productontwikkeling. Deze inzichten helpen je bij het maken van je product roadmap. 

De GO product roadmap

Zodra een team zijn product vision board heeft ontwikkeld, is het tijd om naar een hogere versnelling te schakelen en Roman's GO (Goal-oriented) productroadmap op te stellen. Deze roadmap geeft aan hoe een team specifieke doelstellingen wil bereiken binnen een bepaalde periode en brengt structuur aan in de projectplanning van een team. Uiteindelijk helpt dit proces van het doorlopen van de GO productroadmap om verantwoording te creëren, statistieken te bepalen en een planning op te stellen. 

De GO productroadmap is gemaakt om samen te werken. Oorspronkelijk drukten teams een versie van de roadmap af in posterformaat, hingen hem aan de muur van een vergaderzaal en werkten samen om de roadmap te bedekken met sticky notes en ideeën. Iemand maakte een foto van het eindproduct en digitaliseerde de roadmap om hem met het hele bedrijf te delen. 

Met virtuele whiteboards zoals Lucidspark kunnen teams nu in realtime samenwerken aan een gedeelde roadmap met alle digitale sticky notes en feedbacktools die nodig zijn voor een efficiënte samenwerkingsplanning. 

In plaats van te focussen op de details en verdiensten van afzonderlijke productkenmerken, vraagt de GO product roadmap teams om hun planning te organiseren rond de belangrijkste doelstellingen. Hierdoor is de kans groter dat de beoogde plannen aansluiten bij de strategische doelstellingen en steun krijgen van de leidinggevenden.

Het iteratieve karakter van agile omarmen

Product management tools zoals het product vision board en de GO productroadmap bevorderen de samenwerking en ideevorming in de kern van agile. 

Met agile beginnen teams met een product dat minimaal levensvatbaar is (Minimum Viable Product) en brengen dat op de markt. Bekijk het als de evolutie van persoonlijk vervoer. Henrik Kniberg, een ander bekend lid van de scrum-community, legde dit concept uit door te suggereren dat een minimaal levensvatbaar product voor persoonlijk vervoer een skateboard zou kunnen zijn. Na verloop van tijd verzamelt een agile-team feedback van gebruikers en brengt het verbeteringen aan aan dat skateboard. Het team leert van de eerste versies en ontwikkelt hun 'skateboard' verder tot een scooter, vervolgens een motorfiets en ten slotte tot een volwaardige auto. 

Agile heeft ons allemaal geholpen ons meer op ons gemak te voelen bij het bedenken van ideeën zodra er iets testbaars in de wereld is, in plaats van het hele ding te bouwen en het dan als een afgewerkt product op de markt te brengen. Deze iteratieve aanpak zorgt voor betere respons- en feedbackcycli met gebruikers. Het product dat daaruit voortkomt, is gebaseerd op een sterke basis van echte gebruikerservaring. 

Hoewel het contra-intuïtief kan lijken om slechts een ruwe versie uit te brengen van wat een team hoopt dat hun product ooit zal zijn, vertaalt het uitzonderlijk responsieve ontwikkelingsproces zich uiteindelijk in een veel beter eindproduct. 

Dankzij innovators als Roman Pichler staan product management en met name de rol van de product owner nu centraal in agile, in het bijzonder scrum. En teams en organisaties zijn daardoor beter af.