Doorlopende Discovery in Scrum / Agile Hmm, laat me dat heroverwegen - "Continuous Discovery" is een bekend agile concept dat doorgaans onvertaald blijft, maar de instructie zegt dat ik leesbare tekst moet vertalen. Continuous Discovery in Scrum / Agile

Ik heb al eerder geschreven over hoe agile respectievelijk Scrum-productteams Product Discovery en Product Delivery parallel laten lopen. Daarnaast heb ik geschreven dat teams in de Product Discovery soms graag met Timeboxing werken.

In dit artikel wil ik schrijven over de groeiende trend richting Continuous Delivery en Continuous Discovery.

Het idee van Continuous Delivery (continu opleveren) verspreidt zich steeds meer. Veel teams hebben de afgelopen jaren hierover gesproken, maar inmiddels zijn er ook teams die er echt mee werken. 

Bijna alle productteams werken tegenwoordig met continuous builds. Het principe hierachter is dat het beter is om optredende problemen eerder vroeg dan laat te vinden. Daarom worden de builds normaal gesproken gestart zodra er wijzigingen worden doorgevoerd.

Sommige productteams hebben dit principe naar een heel nieuw niveau getild. Ze hebben geleerd dat integratieproblemen tijdrovend zijn en dat ze door vroege en frequente integratie (in plaats van één enkele fase voor het testen) hun totale doorvoer aanzienlijk kunnen verbeteren als ze de tijd minimaliseren waarin ze geïsoleerd werken.

Evenzo is het beter om continu geautomatiseerde regressietest-suites te draaien om nieuw opkomende problemen zo vroeg mogelijk te detecteren (wat het aantal foutbronnen en de tijd voor het oplossen van fouten aanzienlijk vermindert), in plaats van alles in één fase aan het einde van een release-cyclus (zelfs een tweewekelijkse cyclus) te testen en alle problemen tegelijk te ontdekken.

De logische consequentie hiervan is dat sommige teams nu regelmatig releasen (bekend als Continuous Deployment). Dit betekent dat elke logische verandering (of groep van veranderingen) direct in kleine "micro-releases" wordt opgeleverd. Dit heeft een aantal grote voordelen. Het eerste voordeel is dat dit de ultieme strategie is voor incrementele releases en daarmee het belangrijkste mechanisme voor Gentle Deployment – goed voor onze klanten en goed voor ons. Het tweede voordeel is dat het zoeken en oplossen van problemen in productie veel eenvoudiger is wanneer je steeds maar één of een paar dingen tegelijk wijzigt.

Alles wat ik tot nu toe beschreven heb, heeft echter te maken met Product Delivery. Maar hoe zit het met Product Discovery?

Ik pleit al geruime tijd voor hetzelfde principe als het gaat om het vinden van Product Backlog Items. In plaats van een wekenlange "Product Discovery-fase" waarin je Product Backlog Items opstelt, valideert en vervolgens doorgeeft aan het ontwikkelteam, wil ik teams aanmoedigen tot een continue Product Discovery, waarbij we permanent nieuwe Product Backlog Items identificeren, valideren en beschrijven. Sommige Discovery-werkzaamheden duren slechts een paar uur, andere langer, maar het is een permanent proces van ideevorming, validatie en beschrijving.

In Dual-Track Scrum worden in de Discovery Track continu Product Backlog Items gegenereerd en in de Delivery Track worden deze items continu gebouwd, getest en gedeployed.

Met het oog op de trend van Continuous Discovery en Continuous Delivery vinden veel teams het Scrum-proces een beetje beperkend en beschouwen ze het Kanban-model in dit geval als beter geschikt.

Ook al zijn niet alle teams noodzakelijkerwijs overgestapt naar Kanban, ik heb er toch veel gezien die Scrum precies om deze reden in de richting van Kanban hebben aangepast. De meest voorkomende aanpassing is dat in plaats van na elke bijvoorbeeld tweewekelijkse Sprint te releasen, de features en andere wijzigingen direct worden gereleased wanneer ze klaar zijn – vaak zijn dat meerdere micro-releases per week. In dit geval gebruiken de teams het Timeboxing in Scrum als mogelijkheid om hun werk te structureren en regelmatige Retrospectives te bevorderen.

In principe is de overgang naar Continuous Discovery en Continuous Delivery een heel goede zaak en veel van de beste teams die ik tot nu toe heb leren kennen, werken ermee; ook al moeten er hier, net als overal, soms compromissen worden gesloten.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.