Artikel uit Java magazine 3 2021
Tegenwoordig kun je niet meer ontsnappen aan de Agile werkmethodiek. Als je tijdens het luisteren naar de radio om de haverklap het woord Agile voorbij hoort komen, weet je dat Agile ondertussen niet alleen beperkt is tot het IT-domein. Veel bedrijven stappen in de Agile-boot vanwege de belofte dat het de wendbaarheid ten goede komt. Echter wordt er vaak vergeten te kijken naar de randvoorwaarden die nodig zijn om Agile echt goed te laten werken.
Agile, zoals talloze andere methoden, is niet zomaar te knippen en plakken van organisatie op organisatie. Het is belangrijk om doelgericht te kijken naar de cultuur, het team, de ervaring en kennis binnen de organisatie en talloze andere factoren die de uiteindelijke implementatie en manier van werken zullen beïnvloeden. Organisaties die dit beseffen en hier actief mee aan de slag gaan, kunnen enorme winst behalen uit Agile en ik heb daar in mijn carrière als IT-er de vruchten van mogen plukken.
{ Agile in de context van start-ups }
Scrum, wellicht de meest gebruikte Agile methode, laat het toe om snel en iteratief werkende software op te leveren. Of deze methodiek goed werkt is afhankelijk van de mate van onzekerheid die er heerst rondom dat wat er gebouwd moet worden. Afbeelding 1 toont hoe onzekerheid over een product onderverdeeld kan worden in twee dimensies: de WHAT (wat gaan we bouwen?) en de HOW (hoe gaan we het bouwen?). Naarmate onzekerheid op één van de twee assen verandert, is een bepaalde Agile methodiek meer of minder geschikt.
Afbeelding 1: Twee dimensies van onzekerheid.
Bron: https://www.agile-minds.com/when-to-use-waterfall-when-agile/
Als we focussen op Agile binnen een start-up, dan is er veel onzekerheid op beide assen. Het is nog helemaal niet duidelijk wat de klant precies wil en hoe het team dat technisch het beste kan oplossen. De complexiteit van taken is lastig in te schatten, de scope is onduidelijk, en wat is eigenlijk de echte deliverable bij afronding? Een methode die kan worden toegepast is om dit soort taken als ‘Spike’ op te pakken. Een taak die niet wordt ingeschat op complexiteit, maar wordt getimeboxed op een vast aantal uur dat er aan besteed mag worden. Deze methode werkt goed als Spikes sporadisch voorkomen, maar bij het bouwen van nieuwe producten, waar ook veel UX en wellicht zelfs Data Science bij betrokken is, neemt de mate van taken die erg onzeker van aard zijn exponentieel toe.
Wat je in de praktijk ziet is dat UX, Data Science en engineering taken gericht op onderzoek of verkenning, erg lastig zijn om te laten passen binnen de kaders die Scrum stelt. Om het te laten passen worden er in willekeur story points toegekend aan een taak, dat compleet voorbij gaat aan het doel van story points. Daarnaast verandert tijdens de sprint de taak regelmatig van scope, worden er wellicht nieuwe taken tijdens de sprint toegevoegd (vanwege voortschrijdend inzicht) of wordt de taak van sprint tot sprint meegenomen tot het na een aantal sprints eindelijk klaar is, maar uiteindelijk heeft geleid tot een compleet andere uitkomst dan van tevoren verwacht. Al met al draagt dit absoluut niet bij aan de voorspelbaarheid en wendbaarheid van het team en wordt er dogmatisch getracht dit soort werk te laten passen binnen de Scrum methodiek.
{ Dual track Agile }
Dual track Agile is een methode waarbij er twee onafhankelijke sporen zijn: het ‘discovery’ spoor en het ‘delivery’ spoor. Het discovery spoor focust zich op het produceren, testen en valideren van ideeën. Het delivery spoor focust zich op het opleveren van nieuwe functionaliteit in het product. Bij dual track Agile worden er twee verschillende sporen gebruikt omdat het gaat om twee uiterst verschillende soorten werk en manieren van denken.
{ Het delivery spoor }
Het delivery spoor ben je al gewend om te gebruiken als je volgens Scrum werkt. Alle processen in dit spoor zijn geoptimaliseerd om teams zo wendbaar mogelijk te maken door het wegnemen of verminderen van onzekerheid en het vergroten van voorspelbaarheid. Door dit te combineren met korte cycli, lever je niet alleen voorspelbaar nieuwe functionaliteit op, maar heb je ook een korte feedbacklus die de wendbaarheid weer ten goede komt.
{ Het discovery spoor }
Bij het ontwikkelen van nieuwe producten is, naast delivery, discovery evenredig belangrijk. Zonder gedegen onderzoek naar wat de klant of gebruiker wil, hoe dat zich uiteindelijk vertaalt naar de beste ervaring en hoe dat technisch het beste ontwikkeld kan worden, stuur je letterlijk blind tijdens het bouwen van het product.
{ Discovery in de praktijk }
Zoals Scrum een methodiek is die je moet aanpassen aan jouw organisatie en jouw team, is er ook geen one-size-fits-all oplossing voor dual track Agile. Het proces dat ik hier omschrijf, is het proces dat ik met mijn team hanteer. Discovery is voor ons evenredig belangrijk aan delivery, en hanteren wij een 50/50 split wat betreft tijdsverdeling tussen de twee sporen. In de praktijk hoeft dit niet perse te betekenen dat ieder teamlid daadwerkelijk 50 procent van zijn of haar tijd aan allebei de sporen besteedt. Waar wij echter wel waarde aan hechten is dat het volledige team er bij betrokken is. Van de engineers, designers, data scientists tot aan de product manager.
In vergelijking met Scrum maken we bij discovery geen gebruik van stories met story points, maar hanteren we een Kanban stijl waarbij we redeneren vanuit de meest risicovolle aannames die als hypotheses [1] worden beschreven en gevalideerd. Deze aannames zijn de grote onzekerheden die we willen toetsen. Zoals eerder gezegd kan dit zijn op een technische of niet-technische as (Willen gebruikers dit? Kunnen we dit bouwen met een bepaalde technologie?). Naast de aanname of hypothese bevat een discovery ticket de taken die uitgevoerd moeten worden, de succescriteria en tot slot de tijd die er aan het ticket besteed mag worden.
De product manager, designer, lead engineer en lead data scientist zijn verantwoordelijk voor het leiden van het proces. Het volledige team is betrokken bij het vullen van de backlog. De backlog is een combinatie van ideeën, problemen en aannames die verder uitgewerkt en getoetst moeten worden. Iedere twee weken komen de leads samen om de discovery backlog te bespreken en te prioriteren. Het ordenen en prioriteren doen we door alles op een matrix [2] (afbeelding 2) te plotten.
Afbeelding 2: Aannames matrix.
De horizontale as geeft de mate van onzekerheid aan. De verticale as bepaalt hoe riskant een bepaalde hypothese is. Daarnaast gebruiken we drie verschillende kleuren die aangeven op welk gebied de hypothese betrekking heeft. De drie kleuren representeren de onderdelen van de productontwikkeling [3], namelijk:
- Desirability: Hebben wij een oplossing die de klant echt nodig heeft?
- Viability: Is ons businessmodel winstgevend en duurzaam?
- Feasibility: Kunnen wij dit bouwen?
Ter illustratie: een hypothese toetst of onze klanten bereid zijn om een maandelijkse bijdrage te betalen voor ons product. Dit is een typisch viability vraagstuk, dat tevens vrij riskant is en waarvan de onzekerheid groot is. Zonder betalende klanten is er immers geen geld om het product te onderhouden, laat staan verder uit te bouwen.
Als we inzoomen op de items op de backlog zelf dan proberen we deze zo klein en helder mogelijk te formuleren. Dit zorgt voor gefocuste hypotheses die in een korte tijd getoetst kunnen worden. Hoe kleiner de hypotheses en hoe sneller het resultaat, hoe meer ruimte er is om verschillende experimenteren te doen, en hoe sneller je tot een experiment komt dat slaagt en leidt tot concreet delivery werk.
{ Voor- en nadelen }
Om meteen met de deur in huis te vallen, het grootste nadeel is de extra procesmatige overhead die deze methode met zich meebrengt. Er zijn twee afzonderlijke backlogs met allebei hun eigen manier van werken. Om dit goed te laten werken, vergt het discipline en inzet van alle betrokkenen. Mits je dat goed inricht, brengt het echter een hoop aan voordelen met zich mee. Het zorgt voor een enorme betrokkenheid van het gehele team in het bepalen van de richting van het product. Het hele team leert beter begrijpen hoe het product werkt, wat de gebruiker wil en wat er voor nodig is om dat op een goede manier te bouwen. Daarnaast leidt deze manier van werken tot beter aansluitende oplossingen bij de problemen die de gebruiker ervaart. Door het toetsen van de aannames bouw je geen dure functionaliteit die uiteindelijk niet of nauwelijks gebruikt wordt of verreweg van aansluit bij de wensen van de gebruiker.
Als je kijkt naar het werk van een ontwikkelaar biedt het systeem een gestructureerde vrijheid om het product technisch vorm te geven. Dit kan gaan van het onderzoeken van verschillende oplossingen of het bouwen van ‘proof-of-concepts’. De ervaring in mijn team is dat door het discovery spoor we veel meer tijd hebben en nemen om complexe features of tech debt systematisch aan te pakken. Daar bovenop verminderen we de tijd die we stoppen in het ontwikkelen van software die uiteindelijk niet gebruikt wordt.
Voor een product manager biedt dit systeem het beste van beide werelden. In het discovery spoor biedt het plotten van alle hypotheses op de aannamesmatrix zekerheid dat de focus op de juiste plek ligt, en daarnaast zorgt het timeboxen ervoor dat er voldoende helderheid is over hoe lang discovery werk zal duren. Wat betreft het delivery werk biedt het standaard Scrum proces hen de welbekende garanties door middel van het schatten van complexiteit aan de hand van story points.
{ Tot slot }
Dual track Agile is absoluut geen techniek die een team dat onervaren is met Agile methodieken moet gaan oppakken. Voor zulke teams is het simpelweg het beste om eerst ervaring op te doen met Scrum. Mits je echter een volwassen Agile team bent, en je herkent een hoop van de problemen die ik heb omschreven, dan kan dual track Agile zomaar een toevoeging zijn die het team naar het volgende niveau brengt.
Referenties
[1] https://onlinedialogue.nl/artikelen/hoe-vorm-hypothese/ [2] https://toolkit.highlinebeta.io/assumption-matrix [3] https://medium.com/innovation-sweet-spot/desirability-feasibility-viability-the-sweet-spot-for-innovation-d7946de2183c
Door het discovery spoor hebben we veel meer tijd om complexe features aan te pakken
Marc Rooding
Marc Rooding is Tech Lead bij INGs Wholesale Banking Advanced Analytics en betrokken bij het bouwen van AI producten voor ING en daarbuiten. Hij is een software-architect, polyglot-ontwikkelaar, blogger, occasionele spreker en open-source committer.