Praktische stappen om je release frequentie te verhogen
Deel 4: Begin langzaam en ga steeds sneller
Over de voordelen van vaker releasen, is veel te zeggen. Belangrijke redenen zijn om sneller in te spelen op vragen van (potentiële) klanten, sneller kunnen toetsen van nieuwe functionaliteit bij de eindgebruiker en het verkleinen van risico’s door kleine wijzigingen in productie te zetten. In deze serie van blogs (lees hier deel 1) gaan we ervan uit dat de voordelen bekend zijn. In een apart blog worden de voordelen van vaker software releasen besproken.
Op Techorama heb ik een sessie verzorgd: “Not Netflix, Microsoft or Amazon? Practical steps to increase deployment frequency”. Dit blog is het laatste deel van een vierdelige waarin ik dieper op dit onderwerp in ga. Onderaan de pagina kun je de links naar de eerste 3 delen vinden.
Kleine stappen en dan steeds sneller
Zoals in het in het vorige deel geschreven, weten we dat we in realiseerbare (kleinere) stappen moeten denken om onze lange termijn ambitie te behalen. Nu we dat weten, dan is de volgende vraag: Maar hoe snel moeten we deze stappen zetten?
Je kent misschien wel de quote “Go slow to go fast”. Er is een anekdote dat Abraham Lincoln zei: "Als ik maar een uur de tijd had om een boom om te hakken, zou ik de eerste 45 minuten besteden aan het slijpen van mijn bijl". En dit is een mooie, korte omschrijving die aangeeft wat een goede aanpak is. Bereid je op de juiste manier voor, zorg dat alles in orde is en begin dan. Als je eenmaal begonnen bent zul je zien dat het steeds sneller gaat. Begin niet met een bijl die niet scherp genoeg is. Als je meteen begint lijkt het snel, je bent immers meteen aan het hakken en er gebeurt echt iets. Maar aan het einde zal het langzaam blijken te zijn wanneer de bijl niet scherp genoeg is gebleken en je dit niet van tevoren hebt geslepen.
Zakelijk gezien wordt langzaam beginnen niet altijd gewaardeerd, we hebben het graag over “Fail fast, learn fast” en “Fast feedback”. Langzaam kan worden geïnterpreteerd als iets doen in 5 dagen dat je in 1 dag kunt doen, maar dat is niet wat het betekent. Als we te snel en zonder plan beginnen, kunnen we snel de verkeerde kant op gaan of we kunnen snel gaan zonder onze basis op orde te hebben. En de basis kan het product zijn dat we willen verkopen en opschalen, het kan de organisatie zijn die we willen opschalen maar niet goed genoeg is. Als we snel willen gaan, moeten we er echt voor zorgen dat we de goede kant op gaan met het juiste product en de juiste organisatie, klaar om op te schalen.
Stel je voor dat je geblinddoekt in een veld staat en dat je naar punt B moet. Je kunt gaan rennen, maar je weet niet waarheen. Wat voor obstakels je zult tegenkomen. Als je de juiste schoenen hebt et cetera. Natuurlijk zal 1 op een miljoen de goede kant op rennen en het halen. Maar dat zijn de unicorns. De meesten van ons zijn geen unicorns 😊.
Als je langzaam gaat, zoek je naar het juiste pad. Begin langzaam om te voelen en ervaren welke obstakels je tegenkomt, overwin ze en word zelfverzekerd voordat je sneller gaat. Denk misschien zelfs aan hulpmiddelen om je door het veld te leiden.
Toen ik begon als programmeur (30 jaar geleden alweer) werkte ik samen met een aantal collega’s. Ik was iemand die vaak als eerste begon met het schrijven van de code. Er waren collega’s die op het oog niet zoveel deden, waar ik na 1 dag al iets had draaien hadden zij nog helemaal niets of bijna niets.
Gedurende de daaropvolgende dagen zag je de anderen ook langzaam iets opleveren en aan het einde was ik helemaal niet veel eerder klaar. Wat ik maakte werkte en deed wat het moest doen, dat van de andere collega’s ook. Echter, zij hadden iets beter nagedacht over de opzet, indeling, performance en het onderhoud. Dus na 1 of 2 jaar was mijn code best lastig te onderhouden en goed te laten functioneren, de andere code was dat wel. Op de langere termijn was mijn oplossing dus langzamer, al leek dat niet zo in het begin.
Wat ik hiermee wil zeggen is dat langzaam gaan in dit geval betekende dat de andere collega’s beter nadachten over de oplossing en visualiseerde hoe het zou werken in 1 maand, 1 jaar of nog langer. En door erover na te denken, ging het in het begin langzamer maar het eigenlijke coderen ging veel sneller en op de lange termijn nog veel sneller; dus uiteindelijk konden we vaker releasen.
Conclusie: Een goed begin is het halve werk
Als we kijken naar onze releasefrequentie, de sessie die we vandaag hebben, heeft het geen zin om te beginnen met dagelijks uitrollen als je nu een keer per kwartaal of half jaar uitrolt. Waarom denk je dat je direct naar meerdere keren per dag kunt gaan?
Zet een eerste stap, evalueer hoe dat gaat en wat er gedaan moet worden om een volgende stap te zetten. Denk hierbij aan processen, mensen en ook automatisering. Zet vervolgens de volgende stap, net zolang tot je op een punt bent dat het voor jou de op dit moment ideale situatie is.
Marcel Groennou, DevOps Consultant
Praktische stappen om je release frequentie te verhogen
deel 1: Laat de business en IT samenwerken
deel 2:Eerlijk zijn
deel 3: Neem kleine stappen
