Release early, release often

In de blogpost “Back to Basics” hebben we geconstateerd dat Scrum tien essentiële onderdelen bevat om op teamniveau de basis te leggen voor de transformatie naar een lerende organisatie. Daarbij zijn we twee grote uitdagingen tegen gekomen. De eerste hebben we in de vorige blogpost behandeld waarbij we dieper in zijn gegaan op het onderwerp “Hoe kom je tot een goed geprioriteerde en gebalanceerde product backlog?” In deze blogpost leggen we de focus op de tweede uitdaging: “Hoe zorg je dat het product increment niet alleen frequent wordt opgeleverd, maar ook frequent wordt uitgeleverd?”

Als je aan een Scrum team vraagt: “Wanneer is het werk af?”, wordt hopelijk een antwoord gegeven in de strekking van “Wanneer we aan het eind van de Sprint een bruikbaar en potentieel uitleverbaar product increment hebben opgeleverd. Hoewel dit al een stap voorwaarts is vanuit de situatie waarin we pas aan het eind van een langdurig project een bruikbaar en uitleverbaar product opleveren, vormt dit slechts de helft van de uitdaging. De andere helft van de uitdaging is het aangepast product increment ook snel genoeg aan de gebruikers te kunnen leveren.

Waarom sneller en vaker releasen?

Plain en simple? Software levert pas waarde wanneer deze in de praktijk wordt gebruikt. Hoe sneller we de belangrijke functionaliteit releasen, des te eerder realiseren we de waarde die deze functionaliteit levert. Waarde in deze is niet alleen monetair van aard, maar ook bijvoorbeeld het beperken van potentieel risico, helderheid krijgen over opties of het inzichtelijk krijgen van de behoefte zijn vormen van waarde.

Scrum teams leveren elke Sprint weer een nieuwe versie van het product op, wat zij een potentieel shippable increment noemen. Aan het eind van een Sprint moet dit increment in bruikbare conditie zijn en voldoen aan de “Definition of Done” van het Scrum Team. In de praktijk betekent dit dat wanneer de Product Owner daadwerkelijk besluit het product te releasen het Scrum Team geen additionele werkzaamheden meer hoeft uit te voeren om het product gereed te krijgen voordat het gereleased kan worden.

Één van de grote drijfveren van een iteratief gedreven ontwikkelproces is dat we in staat worden gesteld om sneller te leren. In een hoger tempo potential shippable product increments opleveren levert ons echter maar beperkte feedback op over de technische staat en complexiteit van het product. Ondanks het feit dat het gelukt is om de nieuwe functionaliteit te realiseren in het product, blijft de vraag nog steeds open staan of deze ook schaalt naar duizenden gebruikers? En of deze ook op langdurige basis blijft werken? En of de verwachte ondersteuning voor de business ook wordt geleverd?

Als het gaat om functionele realisatie ontvangen we alleen feedback van de gebruikers en stakeholders die daadwerkelijk bij de Sprint Review aanwezig zijn. Deze feedback gaat in de praktijk vaak alleen over het potentieel en / of verwacht gebruik, niet over het daadwerkelijke gebruik. Kortom, er blijven een hoop vraagtekens open staan. 

Wat als we niet sneller en vaker releasen?

Als we in een hoger tempo potentieel shippable increments opleveren, maar deze slechts infrequent kunnen vrijgeven, ontstaan een aantal problemen binnen de organisatie. Het meest in het oog springende probleem is de complexiteit van het managen van verwachtingen binnen de organisatie. Als we continu werken aan de meest belangrijke onderdelen voor de meest belangrijke doelgroepen, dan is de behoefte aan de werkende oplossing dus ook extreem hoog. En dan is het lastig uitleggen dat een product welke op de juiste manier werkt, op de juiste manier is gebouwd en op de juiste manier is getest, niet in productie kan worden gezet. Probeer dat maar eens uit te leggen aan degene die op het aangepaste product zit te wachten. Een voorbeeld…

In de Sprint Review presenteert het Scrum team onder voorzitterschap van de Product Owner de allerlaatste versie van het product. Niet zo maar een versie, maar het product die wederom de belangrijkste functionaliteit bevat waar de gebruikers met smart op zitten te wachten. De feedback is uitermate positief, het product werkt zoals de gebruikers verwachten en wordt met applaus ontvangen! En dan komt de dodelijke vraag: “Geweldig, wanneer kunnen we dit in onze praktijk gaan gebruike?” … stilte … het Scrum team kijkt met pijnlijke blik weg, de ontstane stilte geeft iedereen een oncomfortabel gevoel. De Product Owner kijkt naar de grond terwijl zacht de harde waarheid wordt uitgesproken: “Over 4,5 maand hopen we deze release in productie te hebben staan.”

Een ander probleem wat ontstaat bij frequente oplevering maar infrequente vrijgave van een product is de exponentiële toename van de complexiteit van het versiebeheer. Hoe langer we wachten met het in productie zetten van de laatste release, hoe groter het probleem wordt wanneer een hotfix in alle tussenliggende versies moet worden uitgevoerd. Of voeren we alleen de hotfix extra door in de huidige versie? Wat als we besluiten terug te rollen naar de vorige versie? Wat als we een tussenliggende versie naar productie willen zetten? Kortom, het in sync houden van veel verschillende versies wordt een complexe taak.

Wat houdt ons tegen?

Als Scrum teams al potentieel uitleverbare versies van het product opleveren, wat staat ons dan in de weg om deze producten ook daadwerkelijk in productie te zetten? Welkom bij het verhaal van de twee werelden. Twee werelden die haaks op elkaar lijken te staan.

In de ene wereld werken product ontwikkelaars nauw met de business samen om in een hoog tempo nieuwe functionaliteiten aan het product toe te voegen. Snelheid en wendbaarheid zijn de sleutelwoorden! Wijze woorden als: “Fail Early, Fail Fast!” zijn uitgeprint en pronken op de gangen. In deze wereld wordt geapplaudisseerd als we nieuwe functies kunnen leveren waar we behoefte aan hebben en snelle besluiten worden genomen. We moeten kunnen inspelen op veranderingen. En hoe sneller we leveren, hoe eerder we de vruchten kunnen plukken.

In de andere wereld werken beheerders en operators dag en nacht om alle systemen in de lucht te houden. Zij werken op basis van prioriteiten aan het oplossen van (potentiële) verstoringen teneinde gebruikers maximaal te faciliteren in de beschikbaarheid van de systemen. Één kleine verstoring (indien niet tijdig verholpen) kan al snel lijden tot een complete onbeschikbaarheid van de totale informatievoorziening en een klein typefoutje kan destructieve gevolgen hebben ( sudo rm -Rf /<enter>pad_naar_onbelangrijke_bestand ). Wijze woorden als: “Don’t fix it if it ain’t broken” hangen hier op de muur. Voorspelbaarheid en stabiliteit zijn key, en als er dan toch iets fout gaat, dan kan het zo maar zijn dat je de rest van de nacht niet meer aan slaap toe komt. 

Deze twee werelden zijn niet eenvoudig te integreren. Elke wereld heeft zich de afgelopen tientallen jaren verder ontwikkelt op basis van een set aan principes die, wanneer goed bekeken, elkaar niet uitsluiten, maar zeker ook niet automatisch gericht zijn op samenwerking. Het gevolg is dat in veel organisaties daarom een grote kloof zichtbaar is tussen de ontwikkel- en de operations afdeling. En wanneer beide werelden, teneinde een lerende organisatie te creëren, naar elkaar toe worden gebracht, leidt dit vaak tot de volgende situatie:

Wat hebben we nodig?

Om een Mexican standoff situatie te vermijden is het van essentieel belang dat een heldere visie, gezamenlijke doelen en duidelijke kaders worden bepaald. De focus van deze visie, doelen en kaders moeten vanuit het perspectief van de klant worden geredeneerd, zodat alle activiteiten in de waardestroom gericht zijn op het leveren van maximale waarde van de klant. Op deze manier wordt duidelijk op basis van welke doelen de waardestroom primair wordt geoptimaliseerd en met welke restrictieve kaders rekening moet worden gehouden. 

In veel organisaties is deze beweging inmiddels ingezet. Vele best practices zijn daarbij geïdentificeerd en worden met elkaar gedeeld. Deze best practices worden vaak gebundeld onder de term DevOps, al blijkt in de praktijk dat er nog geen consensus is over wat DevOps nu wel en niet is. In de volgende blogpost gaan we nader in op DevOps als antwoord op release early, release often. 

Jurjen de Groot is een gepassioneerde Scrum en Agile expert consultant en trainer die gelooft in de eenvoud van de essentie van Agile. Door zijn unieke stijl van coaching laat hij organisaties zien dat een Agile adoptie van onder in de organisatie naar boven verspreid, erg haalbaar is. 

Marco de Jong is een ervaren en resultaatgerichte principal consultant op het gebied van Agile & Lean. Hij is een uitdagende coach en bevlogen trainer met een achtergrond in organisatie ontwikkeling, management en software development. Door zijn eigen stijl van coaching weet hij mensen te helpen het beste uit zichzelf en hun organisaties te halen.