Praktische stappen om de release frequentie te verhogen deel I
Van 4 keer per jaar naar elke sprint
Over de voordelen om 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.
Deel I: Introductie en de eerste randvoorwaarde. Business en IT moeten samen optrekken
Op 11 Oktober 2022 heb ik een sessie op Techorama
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.
Randvoorwaarde 1: Business en IT trekken samen op
De eerste randvoorwaarde is dat het verhogen van de release frequentie alleen succesvol kan zijn als de gehele organisatie hierbij actief betrokken is en zich hier ook aan committeert.
Vaak denken we dat het verhogen van de release frequentie alleen IT raakt, maar het heeft zeker ook invloed op de rest van de organisatie. Hier zijn twee belangrijke redenen voor.
Een stap terug voor twee stappen vooruit
Er is een reden dat een bedrijf nu niet op elk willekeurig moment een release kan doen. En de eerste stappen om hier wel toe te komen, leiden vaak tot een (kortdurende) verslechtering. Stel je voor dat je dit zonder commitment van de rest van de organisatie gaat doen. Bij de eerste verslechtering zal er discussie zijn over de noodzaak van de verandering. Klanten, Sales, Consultants en andere betrokkenen in de organisatie zullen in eerste instantie allemaal eerst ontevreden kunnen worden, voordat de verbetering zichtbaar wordt. Als je de gehele organisatie hierin meetrekt, dan hoef je alleen de klant te managen en voorkom je onnodig veel interne discussie.
Impact op eigen organisatie
Frequentere releases hebben niet alleen impact op de IT-organisatie, ook de rest van de organisatie krijgt er mee te maken. Denk aan Marketing, Sales, Pre-sales en Consultancy. Zij hebben allen een rol in de release van een nieuwe versie. Is het niet het aankondigen en promoten van de nieuwe release vanuit Marketing, dan is het wel het meenemen van de nieuwe functionaliteit in verkoopgesprekken of bij het doen van demo’s vanuit Sales. Als laatste komen consultants bij de klanten over de vloer en moeten zij op de hoogte zijn van de nieuwe functionaliteit en deze ook kunnen toelichten en de klant helpen bij het gebruik hiervan. Allemaal situaties die bij het verhogen van de release frequentie vaker zullen voorkomen en dus zeker impact hebben op de werkzaamheden en planning in de rest van de organisatie.
Conclusie: Samen optrekken
De hele organisatie moet dus akkoord zijn met de verandering, omdat je elkaar nodig hebt om er een succes van te maken.
Praat als IT met de rest van de organisatie en overtuig hen ervan waarom dit belangrijk is. Leg daarna uit hoe dit uiteindelijk zal bijdragen aan het succesvoller maken van de gehele organisatie.
Hoe krijg je de rest van de organisatie mee als ze niet direct enthousiast zijn? Niet door te praten over Sprints, automatisering van releases en builds, Agile of DevOps werken, of andere technische gerelateerde termen. Om iemand mee te krijgen moet je de taal van die persoon spreken. Praat over bijvoorbeeld eerder waarde kunnen leveren aan de klant, kunnen toetsen van hypotheses bij ontwikkelen van nieuwe functionaliteit, kleine stappen doen die minder risicovol zijn, zodat de kwaliteit verbetert of klanten meekrijgen met nieuwe ontwikkelingen. Als je erin slaagt als gehele organisatie op te trekken, is de slagingskans vele malen groter!
Nieuwsgierig geworden en de sessie op Techorama gemist? Op vrijdag 2 december hebben we de sessie van Techorama verkort gehouden (in het Nederlands). Kijk nu het webinar Praktische stappen om je deployment frequency te verhogen terug.
In het volgende blog bespreek ik de tweede randvoorwaarde, “Eerlijk zijn”.
Marcel Groennou, DevOps Consultant
