Devops ervaringen/tips voor beginnende devopsers
Vanaf augustus ben ik in een devops-team gekomen. In eerste instantie was dit team opgericht om de openstaande problemen en incidenten voor de ontwikkelstraat op te ruimen. Voor ons, de devopersers, bestaat deze straat uit 4 scrumteams, productie-incidenten en -problemen en een zijstraat met nog eens 4 teams. Wij zouden deze straat gaan ondersteunen door onopgeloste problemen en niet functionerende software aan te pakken en werkend te maken. Een taskforce die geen functionaliteit zou gaan opleveren, maar problemen van bestaande functionaliteit en ook van de nieuw opgeleverde functionaliteit zouden gaan oplossen om zo het gehele product te verbeteren.
Natuurlijk is dit voor 1 team onmogelijk, maar toch zijn we vol moed en toewijding begonnen met het analyseren van de problemen. Hieruit kwamen nogal wat lijstjes en deze lijstjes verdwenen weer bij een directielid in de la.
Deze lijstjes leek ons niet echt taskforce, laat staan devops. Dus zijn we begonnen om die lijstjes los te laten. Ze te leggen bij de mensen die ze wilden hebben en ons daarmee maar moesten aansturen. Wij gingen ons in de straat zetten als één van de teams. Hierdoor dwongen we onszelf om weer te gaan scrummen. Een goede keuze voor het team. We werden namelijk een team. Een groep die weet waar de expertises liggen en wie er aangesproken moeten worden voor welke problemen. Dit werd het kenmerk voor mij om het team te bekijken als devops. Een team met ontwikkelaars, ofwel developers, en met beheerders, ofwel operations. Zo kunnen de ontwikkelaars makkelijk schakelen met de beheerders over een plan van aanpak. Maar ook kan er snel geschakeld worden om de oorzaak van een probleem te vinden.
Nu we dit hadden moest ons scrumbord opgetuigd worden. Aangezien we anders functioneren dan de andere teams konden we niet zomaar het scrumproces blijven volgen. We maakten ons bord met een extra horizontale lane. De specials lane, die gebruikt werd voor alle issues die door de sprint heen aan het team werd gevraagd. Een voorbeeld waarvoor we de specials lane nog gebruiken is voor de beheerders. Niet alle testomgevingen zijn even stabiel, waardoor de beheerders nog wel eens bezig zijn met andere zaken dan de stories op het bord. Juist daarvoor is deze lane er, om rekening te houden met de tijd die het team buiten de sprint om bezig is.
De specials lane is voor ons ook handig om de tijd buiten de sprint in te perken. We wilden namelijk ook functionaliteit opleveren en de al in stories opgenomen problemen oplossen. Hierdoor moesten we af en toe ‘nee’ verkopen, of ‘ben je al bij de product owner geweest?’. Voor de teams om ons heen niet zo leuk, maar voor ons cruciaal om te kunnen blijven functioneren. En dit moesten we ook naar de andere teams communiceren: De devops is er niet om alle problemen voor je op te lossen. We krijgen problemen op ons bord die niet met een simpele refinement te vatten zijn. We duiken dieper de stof in, maar devops wil niet zeggen dat we de vuilniswagen zijn.
Ons scrumproces bevat dan ook geen refinement zoals scrum dat aangeeft. We hebben in onze tweewekelijkse sprint geen refinement waar we als hele team de stories voor de komende sprint bekijken en klaarmaken. Deze refinement noemen wij analyse en de stories die voor een analyse in de wacht staan nemen we op in de sprint om ze op de goede diepte en waarde in te schatten. Deze analysestories geven dus alleen een oplossingsrichting. Na de analyse wordt dan gekeken of de oplossing de gewenste oplossing is en hoe deze ingevoerd kan worden. Hierbij is het voor ons de taak om de story bij het goede team te zetten. Dit hoeven wij namelijk niet te zijn.
Om te blijven functioneren als devops is het dus van belang om niet alleen lijstjes te maken of te analyseren. Het is juist belangrijk om te doen. Om de expertises te gebruiken binnen het team en daarmee problemen efficiënt op te lossen. Het is hierbij dan ook binnen het team belangrijk om een proces te volgen dat past bij het team waardoor het team kan functioneren. Een extra specials lane of juist geen refinement kunnen de middelen zijn die succes garanderen.