Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Wat gaat er mis met release management?

Expert

Maurice Siteur MBA
Managing consultant, Capgemini. Expert van voor het topic .

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.

Dit artikel delen:

Reacties

Ik ben ook een grote fan van agile approach. Kost idd wat meer tijd maar dwingt costomers ook om prioriteiten te stellen. Scope blijft helder en wat niet past gaat in de backlog.
Probleem dat blijft is dat programmeurs vaak niet goed estimates kunnen schatten.
Zou eigenlijk binnen de opleiding veel meer aandacht aan moeten worden besteed.

De combinatie kan een goed werkend geheel opleveren. De kern zit hem in de genoemde factoren: Requirements vastzetten in samenspraak met de klant, Change control procedures (dit zodat niet continu afgeweken wordt), en met de juiste medewerkers een goede schatting maken qua budget en doorlooptijden, en informeren/communiceren!

De kunst daarbij is om "de opdracht" goed te kunnen vaststellen. Wat is het uitgangspunt van je releasedefinitie. Zodra deze zaken werkelijk de aandacht verdienen in de organisatie, dan kan het goed werken en groeien.

Release management komt uit de wat "traditionelere" ITIL school. Indien goed toegepast kan dit prima werken. Maar over het algemeen wordt het ontwikkelteam gewoonweg te vaak gestoord om tussentijds bugs op te lossen (wat vaak gewoon nieuwe wensen zijn) en overige wijzigingen mee te nemen.

De hedendaagse businesspraktijk vraagt om een snellere time to market en dus kortere releases. Daarmee kun je beter aan de snel veranderende wensen voldoen. Een Agile aanpak kan hierbij een goede oplossing zijn. Dit zien als kleinere releases binnen een watervalmethode kan natuurlijk ook, maar die watervalmethode begint dan toch wel erg Agile te worden.

De vraag is of de agile approach voor release management wel zo bruikbaar is in alle sectoren.

Voor een SW only product, waarvan je de laatste versies kunt downloaden van internet kan een agile benadering je inderdaad helpen.

Maar als de productie een fysieke fabriek is (bijvoorbeeld in het geval van embedded software) en de sofware op een netjes geperste CD met opdruk meegeleverd moet worden (bijv. de CD met hulpprogramma's en drivers bij je nieuwe smartphone) dan zit die fabriek er echt niet op te wachten om iedere 4-6 weken de hele logistieke keten aan te passen omdat er weer een nieuw stukje soft- en of hardware opgeleverd wordt.

Je zou in zo'n geval met een soort pre-release slag kunnen werken met bijvoorbeeld prototypes van de hardware en intern vrijgegeven software. Pas als het hele product klaar en afgetest is, ga je de "echte" productie in, waardoor je maar een éénmalige aanpassing in de fabriek krijgt

Wel interessant dat veel bedrijven dezelfde problemen hebben bij softwareontwikkeling. En dat er al vele oplossingen voor bedacht zijn, die kennelijk ook niet helemaal goed werken, want er worden niet voor niets steeds nieuwe oplossingen bedacht.

Ik vraag mij af of deze problemen zich ook in andere sectoren voordoen. En zo niet dan moeten wij misschien wel software gaan maken op dezelfde manier als men auto's of gebouwen maakt. Hoewel, waarschijnlijk zal ik mijn vak dan minder leuk vinden...

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.