Wat gaat er mis met release management?

In veel projecten wordt onder grote druk gewerkt om deadlines te halen. Vraag je het aan iemand in de organisatie, dan lijkt de deadline bij voorbaat al onmogelijk te zijn. Het probleem van ‘onmogelijke’ deadlines is dat als je geen deadline stelt je zeker weet dat je het niet gaat halen. Prioriteiten komen dan anders te liggen, waardoor het ook daadwerkelijk onmogelijk wordt.

Wat ik merk in veel projecten en organisaties is dat release management er niet is of dat het niet goed is ingericht. Hierdoor is er geen eenduidige scope van wat er naar productie moet. De intentie is: dat kan er nog wel even bij. Vanuit de beste bedoelingen wordt gemorreld aan de scope van de opdracht. De consequenties voor het totale voortbrengingsproces en de implementatie worden niet overzien. Het opstellen van een testaanpak wordt lastiger en de einddatum staat al vast. Projecten lopen dan uit onder zeer grote druk. Onder druk wordt alles vloeibaar en het lijkt wel alsof het zonder die druk niet kan, maar fouten ontstaan wel onder die druk.

Signalen van minder goed functionerend release management zijn:
– Een release is niet gedefinieerd; wat zit er in de opdracht en wat niet;
– Steeds wijzigende releases door druk van buiten het project;
– Tussenreleases die er wel zijn, maar niet in de releaseplanning/nummering voorkomen;
– Onbekend wie verantwoordelijk is voor de releases;
– Release management dekt niet de hele organisatie, waardoor releases elkaar kunnen tegenwerken;
– Tegenvallers in een voorgaande release hebben geen invloed op de volgende release, die gewoon start alsof de vorige release is afgesloten;
– Geen aandacht voor leerpunten uit vorige releases;
– Er is geen rust in de organisatie (rust om verbeteringen door te voeren of om achterstallig werk in te halen).

Bij agile projecten beweren ze de problemen van waterval ontwikkelen niet te hebben. Waar of niet waar? Wat wel opvallend is dat agile gebruik maakt van zogenaamde iteraties, incrementen of sprints. Dit zijn kleine eenheden van werk, die als zodanig naar productie of naar de volgende fase gaan. Mocht een iteratie uitlopen, dan wordt de hoeveelheid werk verkleind en in uitzonderingen nemen we meer tijd voor de iteratie. We gaan dan niet alvast de volgende iteratie opstarten.
In agile worden de iteraties gepland en op hoofdlijnen een aantal iteraties vooruit. Vlak voor een iteratie vindt de planvorming van de iteratie plaats. Geen grote plannen, maar alleen dat wat nodig is. Bijna fabrieksmatig komt de planning tot stand.

Er is maar weinig voor nodig om iteraties als kleine releases te zien. De manier van werken zoals hierboven beschreven is, kan toegepast worden op een watervalachtige manier van werken. Bij het gebrek aan release management ligt volgens mij de kern van het probleem wat er mis gaat in veel organisaties.
Toegegeven, zelfs in een kleinere organisatie spelen veel projecten, die allemaal gepland moeten worden. De kunst van release management is om het geheel in kleine brokken te hakken en beheersbaar te plannen. Een medewerker die release management er bij doet in 5 procent van zijn tijd is dan ook niet de oplossing. Structureel tijd aan release management besteden zal leren dat de organisatie in een relatieve rust kan verkeren. Als de rust er is, dan is het tijd om waakzaam te zijn (zijn we niks vergeten?) en tijd te nemen voor zaken waar anders geen tijd voor is.