In de product lifecycle van een digitaal product komt er een moment dat als product owner een rebuild zal overwegen. Wanneer is het wel een goed idee en wanneer niet? Welke uitdagingen kan je als product owner verwachten en welke stakeholders zijn belangrijk? In dit artikel nemen we je mee hoe je een rebuild effectief coördineert.
Elk digitaal product kent in grote lijnen vier levensfasen, deze worden ook wel de ‘product life cycle’ genoemd. Deze fasen zien er als volgt uit:
Tijdens elke fase kun je er tegenaan lopen dat de gemaakte keuzes niet het beoogde resultaat hebben en het daarom beter is terug naar de tekentafel te gaan. Wij zien in de praktijk een aantal redenen om een rebuild te overwegen.
Achterhaalde techniek
Het komt vaak voor dat systemen zijn gebouwd op een bepaald framework of met een bepaalde codeer-techniek die achterhaald is. In vakjargon spreken we dan vaak over een legacy systeem. Het is dan in de praktijk vaak lastig om nieuwe dingen toe te voegen of nieuwe mensen te vinden. Zie het als Latijn. Er zijn nog steeds mensen die het lezen en spreken, maar ze zijn steeds moeilijker te vinden. Overigens is dit inherent aan IT. Er worden steeds betere en slimmere codeer-technieken ontwikkeld, waardoor bestaande methodieken steeds minder goed gaan aansluiten bij de behoefte naarmate de tijd verstrijkt.
Mocht je product gebouwd zijn op achterhaalde techniek, dan het een goede optie om een rebuild te overwegen.
Technical Debt
Dit zijn doorgaans zaken die in de vorige build niet goed genoeg zijn uitgezocht maar toch in het eindproduct zijn verwerkt. Ook kunnen dit oude incidenten zijn die met een work-around zijn opgelost en daarom nooit echt zijn opgelost. Als dit tijdens de ontwikkeling van een product een aantal keer voorkomt, dan stapelen dit soort kleine defects zich op in wat we ‘technical debt’ noemen.
In essentie is technical debt een backlog van defects die opgelost zouden moeten worden om zaken als stabiliteit en beschikbaarheid te kunnen garanderen. Soms is de technical debt zo hoog dat je beter een nieuw systeem kunt bouwen, in plaats van elke defect individueel op te lossen.
Daarom is het als product owner belangrijk om je bewust te zijn van de technical debt (zet dit op een aparte backlog) en belangrijker, de impact hiervan. Wanneer je die impact meetbaar kunt maken, dan krijg je vanzelf betere discussies met je stakeholder en wordt het eenvoudiger om richting en prioriteit te bepalen.
Probeer bijvoorbeeld je technical debt eens uit te drukken in operationele kosten (OPEX) of in de vorm van MUDA (verspilling). Dit is namelijk rework, één van de zeven verspillingsvormen in LEAN.
Doorlooptijd
Hoe langer het duurt om een product of dienst op de markt te krijgen, hoe groter de kans dat dit geld kost en/of minder omzet genereert. In de Agile werkmethode ‘SAFe’ is hiervoor iets bedacht: de Cost of Delay.
Met deze methode kun je uitrekenen of het nog zin heeft om de huidige koers te blijven varen of dat rebuild een betere optie is. Deze keuze wil je zo min mogelijk aan je onderbuikgevoel overlaten. Daarom bestaan er een aantal guidelines om je op weg te helpen. Dit zijn de drie componenten van Cost of Delay:
- Welke waarde lever je nu voor je eindgebruikers en de business?
- Hoe vervalt deze waarde door de tijd heen?
- Welke risico’s vermijd je of welke kansen faciliteer je?
We snappen dat dit erg abstract is, dus laten we naar een concreet voorbeeld kijken. Neem Netflix; één van de eerste streaming services. Destijds een vernieuwend concept, maar het is – achteraf bekeken – geen rocket science. Er ontstonden al snel concurrenten en Netflix moest op zoek naar manieren om haar klanten te behouden. Zo bedachten ze dat het downloaden van content, zodat gebruikers ook offline van de service gebruik konden maken, van toegevoegde waarde kon zijn.
Omdat er met de tijd steeds meer klanten verliest aan nieuwe concurrenten, speelt tijd een grote factor in het uitrollen van de nieuwe functie. Hoe eerder je dus je kans pakt om een latente behoefte bij je gebruikers los te maken, hoe kleiner de kans dat je achter het net vist. Soms betekent dit dat je op het oude product kan doorbouwen, maar soms wil je jouw product zodanig vernieuwen dat een rebuild de beste optie is.
Niet iedereen waardeert een rebuild
Wees je bewust dat de keuze om een rebuild te doen niet altijd rationeel beargumenteerd kan worden. Stel je voor dat jouw development team ook het oude product heeft gebouwd en dit al jaren onderhoudt. Het is logisch dat je zij weerstand voelen als je een rebuild voorstelt. Verplaats je daarom in hun schoenen, voor praktische tips raden het boek Never Split The Difference aan.
Hoe signaleer je dat het tijd is voor een rebuild?
De eerste signalen kun je opvangen door te meten hoelang het duurt voordat impactvolle features live gaan. Het kan goed mogelijk zijn dat de features die jouw team bouwt, steeds vaker low impact zijn en dat de echte belangrijke features meerdere sprints kosten om te voltooien. Het is makkelijk om in dit geval de schuld bij het team neer te leggen, maar dat is NOOIT de juiste oplossing. Het zou een trigger moeten zijn om te kijken hoe levensvatbaar doorontwikkeling van het huidige systeem is.
Natuurlijk moet je wel duidelijk hebben hoe snel jouw team kan bouwen, dat meten we in de praktijk vaak met Velocity. Maar vergis je niet door te denken dat Velocity alleen te bepalen is door de skills van de developers, sustainability van je systeem is minstens zo belangrijk.
Als we steeds minder grote features opleveren en daar steeds langer over doen, dan is de kans aanwezig dat techniek de oorzaak is. Bespreek het met het team. Komen jij en de meer senior ontwikkelaars tot dezelfde conclusie? Dan is het tijd om keuzes voor te bereiden.
Keuzes voorbereiden
Je eigen huiswerk maken betekent dat je een analyse maakt van de situatie, gevolgd door mogelijke scenario’s. Daarbij is niets veranderen ook een optie. En ook die keuze moet je toelichten.
Wij adviseren om te beginnen met een analyse van de huidige situatie. Welke data toont aan dat een verandering in het platform zal leiden tot het sneller realiseren van waarde voor de gebruiker? Uiteraard heb je geen kristallen bal, dus gaat het uitwerken van scenario’s gepaard met hypotheses.
Burn down chart
Het scrum framework geeft hiervoor een handige tool: de burn down chart. Hierin kun je als product owner bijhouden wat we hierboven hebben beschreven, de hoeveelheid werk die in een sprint is voltooid en wat de openstaande zaken zijn. De burn down chart laat een trend zien. Als die trend laat zien dat er steeds minder waardevolle uitkomsten uit de sprints komen, dan is dit een goede reden voor meer onderzoek. Vervolgens adviseren wij om de ontwikkelaars zelf te laten bekijken wat de alternatieven zijn, al dan niet met de support van een architect. Immers, wij geloven in met mensen beslissen, niet voor mensen beslissen.
Focus sprint
Vind je het moeilijk om scenario’s te schetsen? Voor die situaties gebruiken we vaak de focus sprint, zodat we in één dag met een team de basis kunnen leggen voor een aantal scenario’s, die daarna verder uitgewerkt worden. En ja, dit soort scenario’s moeten ook worden voorzien van een hoogover kostenplaatje. Niemand gaat JA zeggen tegen een (gedeeltelijke) rebuild als het niet helder is hoeveel geld het kost.
Meten is weten
Er zijn veel zaken die je concreet kunt meten die aantonen of een eventuele rebuild nodig is. Vaak komt dat neer op het vergaren en analyseren van data op hoe veel, hoe vaak en met welk doel gebruikers jouw product gebruiken. En natuurlijk is er nog een hele rits aan commerciële KPI’s waarmee je kunt meten of jouw product nog wel relevant genoeg is.
Maar in onze praktijksituaties zien we dat dit soort data vaak ondersteunend is aan de vraag die je als product owner stelt: In welke mate zijn we welwillend om nu even pas op de plaats te maken en/of te investeren, rekening houdend met de gedachte dat we daardoor straks beter (gerichter, sneller, goedkoper, vaker) onze gebruiker van dienst kunnen zijn?
Dat soort aanvullende data moet er zijn, want het laat zien dat je een volledig plaatje kunt schetsen, maar met alleen Google Analytics of wat Power BI dashboarding ga je er niet komen. Wil je meer weten over welke metrics je kunt meten? Google is your friend! Zoek bijvoorbeeld naar “KPI e-commerce” of “KPI platform” en je krijgt veel lijstjes waar je zelf de belangrijkste KPI’s uit kan halen.
Pas op voor vanity metrics
Pas wel op dat je niet in de valkuil stapt om vanity metrics te gebruiken. Dit zijn product metrics die er op papier goed uitzien, maar je niet vertellen hoe goed je product het daadwerkelijk doet, bijvoorbeeld; het aantal user accounts op een platform. Een hoog aantal accounts zegt niks over hoe users je product gebruiken en of ze überhaupt gebruik maken van jouw product.
Keuzes maken
Korte lijntjes met jouw stakeholders over je bevindingen zijn cruciaal om ze mee te krijgen in jouw beslissingen. Want eerlijk is eerlijk, als het gaat over het rebuilden van een platform, dan heb je waarschijnlijk niet genoeg aan je eigen mandaat.
Ons advies is om de beslissers zo vroeg in het traject mee te nemen. Zodra je het onderzoek begint, laat het ze weten. Het meest waardevolle hieraan is dat je vanaf het begin af aan een scherp beeld creëert wat jouw stakeholders nodig hebben om een beslissing te maken. Transparantie werkt in onze ogen vaak twee kanten op. Hoe meer je deelt en vraagt, hoe meer je terugkrijgt als je je als een volwassen PO opstelt.
En als je dat laatste goed doet, dan is de kans groot dat je onderdeel wordt van het team dat de beslissingen gaat maken. dat is cool, toch?
Hoe start je een rebuild traject?
Je bent zover, je hebt een betoog gehouden voor je stakeholders en jullie zijn het unaniem eens om te gaan rebuilden. Dus wat is stap 1?
Om een greep te doen uit Covey’s 7 Habits; begin with the end in mind & first things first. Uiteraard stel je een roadmap op die welke features met welke prioriteit gebouwd gaan worden.
Belangrijk is dat je vooraf beseft dat je voor de aankomende tijd twee platformen in de lucht moet gaan houden. Het huidige platform moet doorgaan terwijl je aan het bouwen bent aan het nieuwe platform. Je kunt hierin kiezen om stapsgewijs functionaliteit over te zetten van het oude platform naar het nieuwe platform, wat je meer controle geeft indien er iets misgaat.
Een tweede optie is een zogenaamde big-bang release te doen zodra de rebuild klaar is. Een big-bang release is minder complex in de zin dat je het huidige platform enkel in de lucht hoeft te houden en geen functionaliteit hoeft uit/over te zetten.
De afweging die je hier maakt zijn: kosten, tijdsdruk, complexiteit en risico. Als je meer dan genoeg budget en tijd hebt en als je team de complexiteit aankan, heeft gefaseerd overgaan de voorkeur. Het risico op falen is hier ook makkelijker te controleren. Heb je minder tijd en moet het huidige platform ASAP uit? Kies dan voor de big-bang release.
Hoe komt dit samen?
We hebben het gehad over: legacy, technical debt, doorlooptijd, metrics en rebuild starten. Het meetbaar maken van technical debt en Cost of Delay gaat je uiteindelijk helpen in het vormgeven van je project, het geeft je een startpunt. Het is belangrijk dat je project een kop en een staart heeft. Ooit moet het af zijn, wanneer is het goed genoeg? Je voelt hem vast al aankomen, maar een Definition of Done formuleren blijft een krachtige methode om de stip op de horizon te bepalen.
Plan voor jezelf reguliere meetpunten om te kijken waar je staat ten opzichte van waar je begon. Product metrics zullen je verder helpen om de interactie tussen jouw product en je gebruikers beter te begrijpen. Kijk niet alleen hoever je nog moet rennen, maar ook de afstand die je al hebt afgelegd.
Vragen of opmerkingen? Neem contact op
Heb je nog vragen omtrent dit onderwerp of wil je ergens anders over sparren? We maken graag tijd om je vragen te beantwoorden en/of kennis te maken met elkaar. Fysiek of digitaal. Neem gerust contact met ons op! Je kan ons mailen via info@productowner.nl of bellen naar +31 85 060 9109.
Vragen of opmerkingen?
Heb je nog vragen omtrent dit onderwerp of wil je ergens anders over sparren? We maken graag tijd om je vragen te beantwoorden en/of kennis te maken met elkaar. Fysiek of digitaal. Neem gerust contact met ons op! Je kan ons mailen via info@productowner.nl of bellen naar +31850609109.
