Hoe staan agile en DevOps met elkaar in verband?

In de ene hoek hebben we de Certified Scrummaster, bij zijn vrienden bekend als de Extreme Programmer, en voor zijn kinderen als de LeSS SAFe DAD... agile!

In de andere hoek hebben we de Lean Culture Machine, die continu levert als het gaat om Infrastructure as Code. Hij noemt zijn linkerarm Dev en zijn rechterarm Ops... DevOps!

Hoewel ik de hype tot het extreme heb doorgevoerd, kunnen de soundbites over agile en DevOps ze laten klinken als heel verschillende ideeën. Beide concepten versterken de verwarring en lijken de definitie te trotseren, ondanks dat ze hun eigen jargon en slogans hebben. Als oudste van de twee is agile misschien minder vaag, maar het is zeker niet ongebruikelijk dat mensen gefrustreerd raken door de talloze definities voor DevOps. Het gebrek aan definitie heeft geleid tot samensmelting op bepaalde punten.

Het historische verband tussen DevOps en agile valt niet te ontkennen. Toen Patrick DuBois en Andrew Clay Schafer op de Agile 2008 Conference over 'agile infrastructuur' met elkaar in gesprek raakten, ontstond de verbinding met DevOps. Hoewel Patrick later pas de term 'DevOps' bedacht, blijft de Agile Conference deze connectie eren met een DevOps-track. Maar laten we verder kijken dan de geschiedenis en de praktische verbanden tussen agile en DevOps bespreken door een kijkje te nemen onder het oppervlak van scrum en continue levering.

In sommige teams is scrum het verschil tussen een constante, frustrerende strijd en productief, lonend teamwork. In andere gevallen vervangt scrum politiek en overmatige toewijding door objectiviteit en focus. Het kan ook worden omarmd alsof het dogma is. Wanneer de beperkingen van het bedrijf of het werk zelf iets anders vereisen, zal een agile team de onderliggende principes van scrum gebruiken, vervolgens hun praktijken inspecteren en zich dan aanpassen om effectiever te worden. Dit is vooral belangrijk wanneer scrum buiten de context van softwareontwikkeling wordt toegepast.

In de DevOps-community erkennen mensen met agile ervaring dat scrum nuttig is voor het volgen van gepland werk. Sommige operationele werkzaamheden kunnen worden gepland: het releasen van een grote systeemwijziging, verplaatsing tussen datacenters of het uitvoeren van systeemupgrades. Maar veel van het operationele werk is ongepland: prestatiepieken, systeemuitval en gecompromitteerde beveiliging. Deze gebeurtenissen vereisen een onmiddellijke reactie. Er is geen tijd om te wachten tot de items prioriteit krijgen in een backlog of op de volgende sprintplanningssessie. Om deze reden kijken veel teams die DevOps-denken zijn gaan omarmen, verder dan scrum naar kanban. Dit helpt hen beide soorten werk te volgen en helpt hen het samenspel tussen hen te begrijpen. Of ze hanteren een hybride aanpak, vaak Scrumban of Kanplan (kanban met een backlog) genoemd.

In veel opzichten kan de sleutel tot de brede acceptatie van scrum zijn dat het geen technische praktijken voorschrijft. De lichtgewicht managementpraktijken van scrum maken vaak een groot verschil voor een team. Waar er ooit concurrerende prioriteiten uit meerdere bronnen waren, is er nu één reeks prioriteiten in de backlog. En waar er ooit te veel werk in uitvoering was, is er nu een plan dat wordt beperkt door wat de tijd heeft laten zien dat echt mogelijk is. In combinatie kunnen deze een team naar een nieuw niveau van productiviteit brengen. Het team kan echter worden beperkt door het gebrek aan technische praktijken, zoals coderingsbeoordelingen, geautomatiseerde acceptatietests en continue integratie.

Andere agile processen zoals Extreme Programming hebben een sterke mening over hoe technische praktijken het vermogen van het team ondersteunen om een vast te houden tempo te handhaven en transparantie en zichtbaarheid te bieden aan management en belanghebbenden. Sommige scrumteams kiezen ervoor om technische taken in de backlog te plaatsen. Hoewel dat goed past binnen de richtlijnen voor scrum, ontstaat al snel het praktische probleem van de voorkeur van producteigenaren ten opzichte van functies. Tenzij producteigenaren vrij technisch zijn, hebben ze mogelijk onvoldoende vaardigheden om de kosten/baten van technische praktijken te evalueren. Dat wordt nog moeilijker voor een producteigenaar omdat de technische taken zich uitstrekken tot operaties om betrouwbaarheid, prestaties en beveiliging te ondersteunen.

Bij Atlassian hebben we ingezien dat het helpt om twee verschillende rollen te hebben voor onze producten. Onze producteigenaren zijn goed in het begrijpen van de functies die gebruikers nodig hebben, maar ze zijn niet zo goed in het afwegen van die functies tegen niet-functionele mogelijkheden zoals prestaties, betrouwbaarheid en beveiliging. Sommige SaaS-producten bij Atlassian hebben dus ook een service-eigenaar, die verantwoordelijk is voor het prioriteren van die niet-functionele mogelijkheden. Van tijd tot tijd moeten de twee eigenaren misschien hard en slim 'onderhandelen', maar meestal kunnen deze rollen worden afgehandeld door onafhankelijke teams. Dit is misschien niet de enige manier om feedback uit de operationele hoek te 'versterken', maar het helpt wel om een al te veel voorkomende voorkeur bij producteigenaren over functies weg te nemen. Deze aanpak met 'twee eigenaren' is niet de enige weg naar DevOps. Het is belangrijk om deze niet-functionele kenmerken te begrijpen als 'functies' en ze te kunnen plannen en prioriteren, net als iederen andere functionele userstory.

Uiteindelijk is geen enkele van deze kritiek op scrum volledig inherent aan scrum zelf. Zoals bij alle agile methoden, heeft scrum een ingebouwd mechanisme voor 'procesverbetering' dat retrospectives wordt genoemd. Daarom is niet onredelijk om aan te nemen dat sommige scrumteams DevOps als inspiratiebron zullen benutten en scrum retrospectief zullen gebruiken als de mogelijkheid om af te stemmen en zich aan te passen aan DevOps. Praktisch gezien is het echter goed om te beseffen dat de meeste teams een injectie van ideeën van buitenaf nodig hebben. Totdat DevOps mainstream is (en misschien zelfs als vak op school wordt gegeven), zal DevOps geen organisch resultaat zijn van scrum. Of het team nu een agile of DevOps-coach inschakelt, is waarschijnlijk niet van belang, zolang die persoon maar ervaring kan bieden in automatisering bij het bouwen, testen en implementeren van software.

Als het goed wordt gedaan, helpt de discipline van continue levering (CD) om het werk in uitvoering te beperken, terwijl de automatisering van implementatie helpt om de beperkingen te verhogen. Op deze manier helpt CD een softwareteam vaker en met een hogere kwaliteit te leveren, in plaats van tussen beide te moeten kiezen. Maar net zoals teams die zich alleen op scrum richten de bredere context van agile kunnen missen, kunnen teams die zich richten op continue levering ook de bredere context van DevOps missen.

De praktijk van continue levering is niet rechtstreeks bedoeld voor problemen in de communicatie tussen het bedrijf en een softwareteam. Als het bedrijf een jaarlijkse, budgetgestuurde planningscyclus hanteert, moet een team dat elke verbintenis in productie levert misschien nog maanden wachten voordat het bedrijf kan reageren. Maar al te vaak komen die reacties als stapfuncties, zoals het annuleren van het project, of erger nog een verdubbeling van het projectteam (omdat een grote toestroom van nieuwe mensen verstorend is).

Het Agile fluency-model geeft het eerste niveau van 'fluency' of vloeiendheid aan als 'Focus op waarde', waarbij teams zich richten op transparantie en afstemming. Zonder deze vloeiendheid kan CD gemakkelijk overgaan in een eindeloze cyclus van technische verbetering die geen merkbare waarde oplevert voor het bedrijf. Een team kan goed worden in het snel leveren met hoge kwaliteit, maar dan voor een product dat een lage waarde heeft voor eindgebruikers of het bedrijf. Zelfs als er veel gebruikers zijn die goede dingen zeggen, is die beoordeling van lage waarde misschien alleen mogelijk op een breder niveau van de bedrijfsportfolio. Zonder deze belangrijke vloeiendheid is het moeilijk om technische praktijken af te wegen tegen functies. Dit is vooral belangrijk voor een team met een oude codebase, dat mogelijk niet beschikt over geautomatiseerde tests of een ontwerp dat geschikt is voor frequente implementatie. In een verouderde context kan een CD-transformatie jaren duren. Het is dus veel belangrijker om zakelijk voordeel te kunnen aantonen.

DevOps is meer dan alleen het automatiseren van de implementatiepipeline. In de woorden van John Allspaw gaat DevOps over 'Ops die denken als Devs. Devs die denken als Ops'. Gene Kim gaat dieper in op die gedachte en legt The Three Ways of De drie manieren uit als principes van DevOps:

Continue levering (CD) richt zich op De eerste manier: het automatiseren van de stroom van dev naar ops. Automatisering speelt een voor de hand liggende rol bij het versnellen van een implementatiesysteem. Maar systeemdenken gaat verder dan alleen automatisering.

De tweede manier wordt gekenmerkt door de praktijk 'Ontwikkelaars hebben ook pagers"Hoewel het letterlijke gebruik van pagers misschien niet nodig is, betekent dit dat ontwikkelaars betrokken moeten worden bij operationele problemen. Dit helpt ontwikkelaars de gevolgen van hun ontwikkelingskeuzes te begrijpen. Dat kan ontwikkelaars bijvoorbeeld inspireren om logberichten op betere plaatsen te plaatsen en die berichten zinvoller te maken. Het gaat niet alleen om bewustzijn. In het geval van probleemoplossing dragen ontwikkelaars ook hun interne begrip van het systeem bij, zodat er sneller een oplossing kan worden gevonden en geïmplementeerd.

De derde manier gaat over het uitvoeren van incrementele experimenten in het systeem als geheel, niet alleen als wijzigingen in de applicatie die door de pipeline beweegt. Met andere woorden, het is relatief eenvoudig om te zien hoe lang automatisering duurt en om een steeds krachtigere infrastructuur te gebruiken om deze te blijven verbeteren. Het is moeilijker te begrijpen hoe de hand-offs tussen rollen of organisaties vertragingen veroorzaken. Dit betekent dat teams de hele leveringsworkflow 'inspecteren en aanpassen', op zoek naar mogelijkheden om de menselijke samenwerking te verbeteren. In CD is het trouwens een vereiste om je te kunnen aanpassen en verbeteren. Als het team niet nadenkt over hoe ze effectiever kunnen worden, en teamleden hun gedrag vervolgens afstemmen op iets anders, zal CD ook niet groeien en floreren. Het team moet zich gesterkt voelen om hun eigen problemen op te lossen.

In scrum is elke retrospective een kans om de praktijken en tools te verbeteren. Maar als het team geen gebruikmaakt van die mogelijkheden om zowel technische problemen op korte als lange termijn op te lossen, wachten ze gewoon tot de producteigenaar CD-taken in de backlog plaatst, wat nooit zal gebeuren.

Scrum komt voor een groot deel overeen met het agile principe 'Verwelkom veranderende vereisten, zelfs laat in het ontwikkelingsproces. Agile processen maken gebruik van verandering voor het concurrentievoordeel van de klant.'

Continue levering komt voornamelijk overeen met het agile principe 'Onze hoogste prioriteit is om de klant tevreden te stellen door vroege en continue levering van waardevolle software.'

Dat betekent dat agile meer gaat over het omarmen van inkomende en uitgaande verandering dan over ceremonies zoals standups en sprintplanning. Maar het Agile-manifest bevat inderdaad nog 10 andere principes. In plaats van te proberen uit de principes te kiezen, moeten ze als geheel worden beschouwd. Samen vertegenwoordigen deze principes een houding ten opzichte van verandering die gebruikelijk is voor zowel agile als DevOps.

Deze mensen waren veroordeeld tot het werken met kwetsbare systemen die ook nog eens het belangrijkste zijn voor het bedrijf. En omdat ze het belangrijkst zijn voor het bedrijf, zijn het ook de systemen waar de meest urgente veranderingen nodig zijn. Als zodanig is dit agile idee om verandering te omarmen geen 'verandering omwille van verandering'.Het gaat erom ontwikkeling verantwoordelijk te houden voor de kwaliteit van hun veranderingen en tegelijkertijd de algehele capaciteit te verbeteren om bedrijfswaarde te leveren. Deze focus op bedrijfswaarde is een ander aspect dat wordt gedeeld door agile en DevOps.

Uiteindelijk zijn noch agile, noch DevOps zakelijke doelen op zich. Beide zijn culturele bewegingen die de organisatie kunnen inspireren met betere middelen om de doelen te bereiken. Agile en DevOps werken beter in combinatie dan als tegenstanders. De truc om confrontaties tussen deze twee ideeën te vermijden, is om de diepere waarden en principes te begrijpen waarop ze zijn gevormd. Snelle, maar smalle definities leiden tot silo-denken.Nu je weet dat er meer bij agile komt kijken dan scrum, en DevOps meer is dan CD, ben je klaar om de krachtige combinatie van agile + DevOps uit te proberen.