Tips en achtergronden over een Big Bang implementatie in een agile werkomgeving.

Agile Manifest

Wat de 10 geboden voor het Christendom én Jodendom zijn, dat is het Agile Manifest voor IT-ontwikkeling. Vereer naast mij geen andere goden… daar houdt de hele IT zich aan. Wij omarmen agile en dulden geen andere goden, zoals waterval of RUP, meer. Maar niets menselijks is de IT vreemd: ook daar wordt gezondigd tegen het eerste gebod.

Net zoals de 10 geboden, als je ze naleest, uit 3 geboden en 12 verboden bestaan, zo kent het Agile Manifest ook 4 waarden en 12 principes. Een schending van deze principes is een hoofdzonde en dit artikel beschrijft hoe we helaas nog vaak zondigen tegen het allereerste Agile principe:

“Onze hoogste prioriteit is het tevredenstellen van de klant
door het vroegtijdig en voortdurend opleveren van waardevolle software”

Redenen om vroegtijdig en voortdurend op te leveren

De voordelen van het eerste Agile principe zijn helder. Als je vroegtijdig software oplevert dan krijg je ook vroegtijdig feedback terug. En met vroegtijdige feedback kan je vroegtijdig je product verbeteren. Door voortdurend de software op te leveren, groeit het in kleine stapjes. En de richting van de stapjes kan je elke sprint weer bijstellen. Zo groeit steeds het belangrijkste stukje van de software. Dat is de kern van agility: wendbaarheid in optima forma.

De onvermijdelijke Big Bang

Een voorwaarde voor vroegtijdige oplevering is dat er een kleine subset bestaat die zelfstandig is op te leveren en waardevol is: een Minimum Viable Product (MVP). En soms is een MVP niet klein te krijgen. Typerend is de implementatie van ERP systemen, die juist hun voordeel vinden in grootschaligheid. Maar we zien ook grote MVP’s bij het vervangen van omvangrijke legacy systemen in een applicatielandschap met tientallen afhankelijke applicaties en honderden interfaces.

Puristen zullen claimen dat ook grote systemen klein beginnen, maar er schuilt een exponentieel probleem in het stap-voor-stap vervangen van grote applicaties: het synchroon houden van de onderliggende data, dubbel onderhoud en een steeds ingewikkelder wordende configuratie van systemen die gedeeltelijk op het nieuwe systeem zitten, maar niet voor alle interfaces. Dit kan een jarenlange spaghetti van steeds complexere onderlinge afhankelijkheden opleveren. Een risico op zich!

Een ander punt is dat tijdens zo’n stap-voor-stap transitie de urgentie om de rest te doen daalt. Zo loopt het proces steeds langzamer… tot het soms zelfs stopt. Dit laat dan een hybride applicatielandschap achter.

En dan zijn er ook nog derde partijen/leveranciers bij betrokken. Die kunnen een grote wijziging in één keer verkiezen boven een (jaren)lange stroom van kleine wijzigingen.

Tijd voor metaforen:

• De mens is prima in staat om kleine verwondingen stap voor stap te helen. Maar bij een harttransplantatie moet het toch echt in 1 keer.
• De Big Bang theorie is de meest gangbare theorie voor het ontstaan van het heelal. Zelfs dat God de wereld schiep in 6 dagen kan je als een Big Bang zien. Ook al deed Hij er dan 6 dagen over, het was geen proces waarbij Hij een kleine stap zette om van Zijn fouten te leren en Zichzelf te verbeteren. God maakt immers geen fouten, dus had Hij geen noodzaak om te leren. Hij is meer iemand van First time right.
• Jij kwam in 1 keer op de wereld. Je moest vanaf dag 1 zelf ademhalen, drinken, eten en alles wat daarbij hoort.

Er zijn dus duidelijk situaties waar een Big Bang onvermijdelijk is. Maar toch willen we in de IT de voordelen van agile werken behouden. Dan rijst de vraag: Hoe dan?

“Verzin toch eens een list, jonge vriend!”
Olivier B. Bommel

Tom Poes verzint een list

De list die ik heb zien werken, is die van de parallel adoption. Bij deze methodiek ontwikkelt een nieuw systeem zich in een productie-like omgeving naast het productiesysteem. Het nieuwe systeem ontvangt dezelfde input als het productiesysteem, en testen tonen aan dat het nieuwe systeem gelijke of betere resultaten geeft dan het productiesysteem. De ontwikkeling van het nieuwe systeem kan agile gebeuren, dus met kleine stapjes en regelmatige oplevering.

Dat geeft wel een set aan nieuwe problemen om te tackelen:

• Het nieuwe systeem voeden kost extra tijd. Kijk daarom naar geautomatiseerde input: is er een stroom die je automatisch kan aanbieden in plaats van handmatig? Of kan een handmatig ingevoerde data-stroom van productie worden afgetapt naar het nieuwe systeem?
• Productie gaat voor. Als iemand moet kiezen tussen het uitproberen van het nieuwe systeem of het verhelpen van een productieprobleem, dan gaat dat nieuwe systeem het loodje leggen. Een apart team inzetten, los van productie, kan hier een oplossing bieden.
• Ook bij de andere teams die bijvoorbeeld moeten aansluiten op het nieuwe systeem, kunnen productie-issues voorgaan, waardoor die aansluiting op het nieuwe systeem op zich laat wachten. Een kwestie van prioriteit en daar gaat de Product Owner over. Het is dus essentieel dat PO’s van aansluitende systemen zich bewust zijn van hun aandeel in de voortgang. Zij moeten die verantwoordelijkheid krijgen én voelen.
• Het nieuwe systeem heeft een initiële vulling nodig, een migratie van de data uit het productiesysteem. Dit kan een langdurig proces zijn, zoals DUO in 2018 aantoonde. Maar dit onderdeel leent zich heel goed voor het principe Release Early, Release Often. Door vroeg in het project te starten met migraties die het team met grote regelmaat uitvoert, krijg je niet alleen een door-en-door geoefende migratie, maar ook meteen een focus op de migratie-doorlooptijd. Om het simpel te zeggen: een wekelijkse migratie kan geen maand duren.
• Bij een Big Bang gaat niet alleen het nieuwe systeem over, ook alle aansluitende systemen krijgen nieuwe interfaces, of misschien nieuwe datasets, of gaan over op een ander werkproces. Ook deze transitie moet geoefend en getest worden. Misschien niet zo vaak als de migratie, maar oefenen is nodig om de kans op verrassingen bij de Big Bang te verkleinen.

Na de Big Bang

Het grootste nadeel van een Big Bang blijft het risico op onverwachte problemen tijdens de Big Bang zelf: hoe vaak je ook oefent, in ‘het echie’ gaat het toch vaak anders. Bekende voorbeelden zijn de Free Record Shop en meer recent: Pluripharm. Wat je dan nodig hebt is de flexibiliteit om snel op de problemen te kunnen acteren. Een capabel team dus dat over een gesmeerde software-pipeline snel verbeteringen naar productie kan brengen. Hier komt een heel rijtje buzzwoorden aan de orde, die ik kort zal toelichten:

• DevOps: het samenbrengen van softwareontwikkeling en de software operations. Als je het beheer in een ontwikkelteam trekt, dan kan het team productieproblemen beter zien en sneller software naar productie brengen.
• Continuous delivery: Geen releases, maar een continue stroom van nieuwe software. Zodat verbeteringen nooit wachten op ‘de volgende release’. Dit vereist een geautomatiseerde ontwikkelstraat tot en met productie, dus:
• Versiebeheer: een constante stroom van nieuwe software betekent dat aan veel softwarewijzigingen tegelijk wordt ontwikkeld. Dat kan alleen goed naar productie gaan met goed versiebeheer.
• Continuous testing: als elke dag meerdere software-versies naar productie gaan, moeten de tests  geautomatiseerd zijn. Een foutloze test-uitvoering is een geautomatiseerde voorwaarde van de ontwikkelpipeline.
• Continuous deployment: het stopt niet bij een foutloze oplevering. De ontwikkelpipeline moet tot en met de uitrol op productie reiken. En dat het systeem in productie, dus ‘gewoon’ overdag, kan worden bijgewerkt, hoort daarbij. No guts, no glory.

Terug naar onze metaforen:

• De metafoor over de harttransplantatie werkt niet. Maar wil je er meer over weten: Eurotransplant is een opdrachtgever van ons.
• De metafoor met de Big Bang en het scheppingsverhaal gaat ook al mank, want hoewel beide theorieën onderling enorm verschillen, zijn ze het over 1 ding wel eens: vóór het ontstaan van de wereld was er niets.
• De metafoor over geboorte werkt daarentegen perfect: de parallel adoption komt precies overeen met zwangerschap, stap voor stap groeien en je voorbereiden voor de buitenwereld. Daarna helpen jouw ouders je om te gaan met die buitenwereld, zelfs zonder kennis over DevOps of Continuous deployment.

Agile een Big Bang uitvoeren: het kan

Conclusie: je kan op een agile manier software via een Big Bang naar productie brengen. Door het nieuwe systeem in een parallelle omgeving stapsgewijs te laten groeien, benut je de voordelen van agile werken. Het kost extra tijd in de voorbereiding. En er zijn extra maatregelen nodig om de grotere risico’s van de Big Bang te mitigeren.

Sterker nog, juist omdat de risico’s zo groot zijn, heb je een ‘super’ agile werkproces nodig, zodat je direct na de Big Bang om kan gaan met onverwachte zaken. Murphy’s Law blijft bestaan, dus gaat het erom dat je de mogelijkheden hebt om daar flexibel op te reageren: wees agile!

Interesse gewekt?

Vond u dit artikel interessant? Deel het met uw netwerk!

Meer weten? Lees ons gratis e-book over de impact van agile werken, of neem deel aan onze trainingen die zijn gericht op een flexibele werkwijzen en agile organisaties.