DevOpsDOES 2019 – Londen – The dawn of a new DevOps era…A must read

Afgelopen 25 t/m 27 juni was de 2019 editie van de DevOps Enterprise Summit (DOES) in Londen. Deze summit bestaat uit een community van mensen die voornamelijk in grotere organisaties werkzaam zijn en hierin met DevOps te maken hebben. Deze summit wordt twee keer per jaar gehouden. Een keer in Las Vegas en één keer in London. De summit is een conferentie die bestaat uit drie dagen vol met sessies waarin goede sprekers hun ervaringen delen over de DevOps transformaties binnen hun organisaties. Dit heeft als doel kennis en ervaringen te delen en van elkaar te leren. Ook wordt er gedeeld welke uitdagingen de verschillende organisaties zien voor de toekomst en hoe ze deze willen aanpakken. Vanuit Delta-N hebben we deze summit bezocht met twee DevOps consultants. In dit artikel de punten die ons zijn opgevallen.

DOES 2019 - London

People

Waar de DevOps definitie al jaren elementen bevat als tooling en proces, is misschien wel het belangrijkste wat is opgevallen, dat de focus in DevOps-land tegenwoordig erg over de mensen gaat. De cultuur, verandermentaliteit om samen met medestanders dingen echt te veranderen, het mogen of zelfs moeten falen en mislukken, doorzettingsvermogen, verantwoordelijkheid, en continue willen verbeteren en aanpassen, zijn hierin belangrijke elementen. Wat hierbij aansluit is dat we niet alleen better, sooner en safer waarde willen leveren voor de eindklanten, maar ook op een happier manier. Medewerkers, opdrachtgevers en klanten dienen in een happy omgeving aan leuke dingen werken. Dit draagt voor een groot deel bij aan de waarde die geleverd wordt.

Een minder belicht onderdeel, maar niet minder belangrijk is het fenomeen wat bekend staat als een burn-out. Hier werd over verteld aan de hand van echte voorbeelden. Over de signalen die we met zijn allen kunnen zien en iets mee moeten doen. Best wel confronterend, maar ook zeker leerzaam.
Er werd ook veel verteld over soorten personen, de verschillende skillsets, de specialisten en generalisten, maar het meest opvallende was misschien wel dat er gesproken werd over personen in de typen blockers en enablers. Mensen die tegenhouden, terecht kritisch zijn, en mensen die ijs breken, en nieuwe wegen mogelijk maken. Beide zijn waardevol, maar zonder enablers is vooruitgang moeilijk. De boodschap was dan ook om ervoor te zorgen dat je voldoende enablers in je organisatie hebt en dat je ze de kans geeft zaken te veranderen en te verbeteren.

Gene Kim tijdens DOES Londen
Gene Kim, één van de sprekers op DOES

Cloud en infra

Natuurlijk is er ook veel gesproken over de cloud in relatie tot DevOps. Enterprises maken veel gebruik van de cloud en maken steeds meer de move naar SaaS-componenten en services. Dit heeft implicaties voor medewerkers die in meer traditionele operations rollen zitten. Met het principe “You build it, you run it!” wordt in veel organisaties duidelijk dat de rol van operations ook in het team moet zitten omdat het team verantwoordelijk is en blijft voor als de software in productie draait. De infrastructuur en services worden steeds meer geautomatiseerd en operations mensen hebben een duidelijkere rol in het monitoren en verwerken van gebruikersfeedback en het onderhoud van de services.

Teams en management

Er is veel gesproken over teams, en hun indelingen, en hoe management hier een rol in heeft. Heel veel bekende dingen die we al weten, maar nog lang niet altijd (goed) uitvoeren. Inmiddels is wel duidelijk dat als je veranderingen in werkwijzen wil doorvoeren, je klein moet beginnen. Starten met één team en dan langzaam uitbreiden. Belangrijk hierbij is dat als je aan het uitbreiden bent, je ook continue blijft veranderen. Doordat er meer teams op de DevOps manier gaan werken ontstaat er ook een andere dynamiek in de organisatie. Hier moet je rekening mee moet houden en dus mee veranderen. Doe je dit niet is de kans op falen groot.

Ook een belangrijke om te onthouden hierin is dat we vaak te snel willen. Een mooie uitspraak in één van de sessies was dan ook: “To go fast, you need to go slower”. Wat zoiets betekent als; als je wilt veranderen je hier de tijd voor moet nemen. Iedereen heeft tijd nodig om aan te passen en mee te veranderen. Zoals eerder geschreven is het hebben van alle benodigde expertise in de teams een must. Cross-functional teams weten nu eenmaal meer en kunnen samen de verantwoordelijkheid dragen voor het creëren van waarde. Een cultuur aspect hierin is dat de schuldvraag zoveel mogelijk achterwege blijft. Een goede aanpak is om meteen te leren en aan te passen. De vraag stellen hoe we het de volgende keer beter kunnen doen en/of voorkomen is een goed startpunt.

Het laatste wat opviel als je over teams hebt, is dat het managementteam eigenlijk het eerste team is dat moet veranderen. Vaak zijn trainingen nodig hiervoor, zodat het management ambassadeurs worden van de veranderingen. Ze dragen niets op, maar ondersteunen veranderingen en faciliteren deze ook. Succesvolle managers staan dicht bij de teams en helpen ze creatief te zijn en natuurlijk vooral om waarde te creëren en te verbeteren. Oprechte empathie en goed kunnen luisteren zijn hier key. Alleen dan zullen teams beter functioneren en komen uiteindelijk unieke te creëren waarden uit de teams. De teams weten tenslotte beter wat er speelt dan de managers. Dit concept wordt ook wel servant leadership genoemd en hier is veel informatie over te vinden op het internet. Gerelateerd hieraan is het conceptueel veranderend denken van projecten naar producten. Projecten zijn mooi als deze gerealiseerd worden maar zijn geen doel op zich. De waarde voor de eindgebruikers en klanten zit in de producten!

Timetheft

Een ander interessant onderwerp was de tijd die we aan zaken besteden. Zo werd er veel over de Flow gesproken, Lead Time en andere bekende vergelijkbare concepten. Wat een eyeopener was, is dat uit diverse onderzoeken is gebleken, dat om een stuk af te ronden er 50% van de tijd in de mensen gaat zitten. Het begrijpen, uitwerken, realiseren etc., allemaal mensenwerk. Daarnaast is 37% van de tijd nodig in het proces, zoals alle stappen die doorlopen moeten worden en statussen die veranderen. De rest zit in andere kleinere zaken, maar voornamelijk in de tools die we gebruiken. Traditioneel besteden we echter veel energie en tijd aan deze laatste categorie om hier verbeteringen in aan te brengen. Gezien de percentages zouden we dus misschien aan de eerste twee meer tijd moeten besteden, omdat hier meer winst te behalen valt.

We hebben in het algemeen trouwens snel last van Timetheft. Tijd die je ontnomen wordt door allerlei oorzaken. Wist u dat uit dezelfde onderzoeken is gebleken dat van de tijd dat een idee ontstaat tot de realisatie ervan 95% er niets of nauwelijks iets gebeurt met dat item? We doen wel andere belangrijke zaken in die tijd, maar er gebeurt dus vaak niets met het item. Daar valt nog wel wat winst te behalen!

Swarming

Een mogelijk minder bekend concept is het concept van swarming. Ook hier is veel over te vinden op het internet. Wat erg opviel, is dat als de swarming goed is ingeregeld in de organisatie, dat er een aantal voordelen duidelijk worden. Bijvoorbeeld: de vele lagen van een traditionele servicedesk zijn er niet meer. Dit komt omdat er een swarm (groep mensen met expertise) pas wordt opgericht als er een issue binnen komt. Deze mensen die een swarm vormen, zitten in de normale teams, en zijn direct betrokken bij operatie. Een tweede voordeel is dat iedereen deelneemt aan swarms, en het leereffect hierdoor weer aanzienlijk vergroot wordt. Een mooie uitspraak die we hoorden: “Iemand werkte al 20 jaar op de servicedesk van een organisatie. Na de inrichting van swarms heeft hij zijn kennis in 1 jaar tijd verdubbeld!”

Als laatste voordeel is te zien dat de hoeveelheid van ticket-tennis aanzienlijk verminderd wordt. De tijd dat een ticket zwerft om bij de juiste persoon uit te komen om na het oplossen dezelfde weg terug weer te volgen, is tenslotte verloren tijd.

Tot slot

De ervaringen die we hebben opgedaan zijn bijzonder en we hebben er veel van geleerd. In deze blog hebben we slechts een aantal zaken besproken omdat het simpelweg niet mogelijk is alles weer te geven. Houd de website en social mediakanalen in de gaten voor nog meer informatie, artikelen en achtergronden. Wij gaan er mee aan de slag! Wil je meer weten? Of kunnen we helpen met één van de onderwerpen? We willen graag een uitgebreide toelichting komen geven. Neem hiervoor gerust contact op met ons.

Meer informatie en naslag:

Fabian Biesheuvel, DevOps Consultant
Fokko Veegens, DevOps Consultant