Praktische stappen om je release frequentie te verhogen
Deel 5: start niet met technologie
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 gaan we ervan uit dat de voordelen bekend zijn. In een apart blog worden de voordelen van vaker software releasen besproken.
Op het technologiecongres Techorama heb ik een presentatie mogen geven: “Not Netflix, Microsoft or Amazon? Practical steps to increase deployment frequency”. In een serie van blogs deel ik de tekstuele toelichting van deze sessie. De slides zijn via deze link te downloaden.
Focus niet te veel op technologie
Zoals in deel 3 geschreven, weten we dat we in realiseerbare (kleinere) stappen moeten denken om onze lange termijn ambitie te behalen. Ook weten we dat we langzaam moeten starten om steeds sneller te gaan. Maar waar moeten we nu beginnen?
Het grootste deel van deze blogserie gaat niet over technologie. DevOps gaat immers over People, Process en Tools. We kunnen veel problemen en uitdagingen ogenschijnlijk (eenvoudig) oplossen met tools en technologie. Maar dit is ook onze valkuil, we hebben de neiging om (te) veel op techniek te focussen. Het is vaak een veilige keuze, we focussen op de IT en IT-afdeling(en) en doe daar de verandering. Reden hiervoor is dat als we dat doen we niet hoeven te praten met de business. Zij zijn immers vaak niet betrokken bij onze technologische keuzes dus dat kunnen we binnen de IT-afdeling besluiten. Ook doet de technologie gewoon wat we zeggen. Geen pushback, geen lastige discussies. En last but not least, techniek is wat wij als IT-organisatie beheersen. Wij worden enthousiast als we dingen kunnen automatiseren en nieuwe technologieën kunnen implementeren.
Maar als je alleen op IT richt, kun je de verkeerde beslissingen nemen. Wat is het knelpunt bij vaker releasen? Is het testautomatisering? Release automatisering? Zijn de user story’s te groot? Is het ontwikkelproces niet goed ingericht? Werkt de business niet samen met de development organisatie? Is het de samenwerking met onze klanten? Er zijn zoveel dingen die veranderd kunnen worden, maar het is moeilijk om de meest urgente te identificeren. En door alleen op techniek te concentreren maak je de kans dat je het verkeerde kiest nog groter.
Implementatieduur van IT
Een ander probleem bij het focussen op IT is dat het even duurt voordat het geïmplementeerd is. Nieuwe tooling kiezen, alles naar één engineering systeem verhuizen, pipelines bouwen, testen automatiseren et cetera zijn allemaal stappen die maanden of jaren kunnen duren terwijl je eigenlijk niet goed weet wat de beste volgende stap is als je de releasefrequentie wilt verhogen.
Simpele stappen die je snel kunt doorvoeren zijn vaak effectief om de echte problemen boven water te krijgen. Start met het beperken van het aantal items waar je aan werkt, de work in progress (WIP). Je zult al snel zien dat het op allerlei plekken gaat wringen omdat heel veel zaken buiten de technologie niet goed zijn ingericht. Of ga kijken hoelang het duurt vanaf het moment van oppakken van een user story totdat deze gereed is. Hoelang duurt dat? En hoe kunnen we dat korter maken? Of zit daar wachttijd ergens verborgen?
Neem kleine stappen
Zorg in ieder geval dat als je wilt verbeteren dat je direct begint en snel de eerste resultaten inzichtelijk krijgt. Als dit te lang duurt dan is de kans groot dat de verbetering niet wordt doorgevoerd. De wil is er wel maar aangezien resultaten uitblijven gaat een organisatie zicht richten op nieuwe uitdagingen. We gaan nu eerst deze nieuwe klant onboarden, we bouwen nu eerst deze nieuwe feature voor een bestaande klant en kijken daarna wel weer verder naar waar te verbeteren. Neem kleine stappen die je eenvoudig en direct kunt doen, de eerste resultaten zullen zichtbaar worden en dat motiveert weer voor de volgende stap. Voor je het weet is het continue verbeteren onderdeel geworden van de manier van werken binnen de organisatie. En uiteindelijk zullen ook de grotere veranderingen opgepakt worden.
Marcel Groennou, DevOps Consultant
