Foute keuzes na gemiste deadlines in een agile omgeving

1. Introductie

Scrum teams hebben net als traditionele waterval teams te maken met deadlines. Om diverse redenen kan het voorkomen dat nieuwe functionaliteiten niet op tijd gereleased worden. Dat is zuur. Zeker omdat de volgende wijzigingen vaak al in de planning zijn opgenomen.

2. Combineren van releases

Een voor de hand liggende oplossing lijkt het combineren van de verschillende releases. Dan kun je bijvoorbeeld alle testen combineren en hoef je alles maar 1x te testen. Hierdoor creëer je tijdwinst en kom je de eerstvolgende release weer in de normale heartbeat (cadans).

Het tegendeel is echter waar. Het samenvoegen van releases levert geen tijdwinst op. Het kost zelfs meer tijd. Veel meer tijd.

Oorzaken zijn onder andere:

– Door meer te wijzigen wordt de scope vergroot en neemt de kans op defects toe. Blijft het aantal ontwikkelaars gelijk dan ontstaat er een defect queue (bottleneck). Testen staan hierdoor stil totdat fixes worden opgeleverd. Een grotere scope leidt tot een exponentieel grotere defect queue.
– De development- en testinfrastructuur blijft hetzelfde. Hierdoor ontstaat wachttijd (waste). Zo kunnen sommige testen bijvoorbeeld niet parallel uitgevoerd worden op dezelfde testomgeving waardoor ze op elkaar moeten wachten.
– De coördinatie en afstemming tussen teams en afdelingen neemt exponentieel toe.
– Omschakeltijd. Schakelen tussen verschillende activiteiten kost tijd. Voorbeeld: Een teamlid stuit tijdens het testen op een blokkerend defect en wil hierdoor een andere test opstarten. Hiervoor moet eerst nieuwe testdata klaargezet worden, ingelogd worden met een ander gebruikersaccount, etc.
– Scopecreep. Hoe langer een release onderhanden is, hoe meer “extra functionaliteiten” van alle kanten toegevoegd worden. Denk hierbij bijvoorbeeld aan hotfixes.

Kortom: Het vergroten van de scope zal dus door verschillende oorzaken exponentieel toenemen.

3. Release early, release often

In plaats van de scope te vergroten door releases te combineren adviseer ik met klem het tegenovergestelde. Maak de scope juist kleiner zoals het Agile Manifesto ook voorschrijft en release vaker.

De volgende technieken kunnen helpen bij het verkleinen van de scope:

– Dark Launches: Release van code naar productie waarbij de functionaliteit niet beschikbaar/zichtbaar is voor de eindgebruiker.
– Feature toggles: Een techniek waarbij je gebruik maakt van Dark Launches waarbij je de mogelijkheid inbouwt om de functionaliteit op een later tijdstip alsnog aan/uit te zetten.
– Canary release: Een techniek waarbij je de functionaliteit alleen beschikbaar maakt voor een selecte groep gebruikers. Vervolgens meet je de feedback en kun je er voor kiezen om op een later tijdstip de functionaliteit alsnog te releasen naar meer gebruikers.
– Decouple release elements: Een release kan in de regel opgeknipt worden naar kleinere elementen die apart van elkaar live gebracht kunnen worden.