In 6 concrete stappen maak je een start met jouw DevOps reis. First things first. Dit blog is een subjectief iets. Ik deel graag mijn ervaringen, mijn kennis en mijn manier van werken met jou zodat dit ter inspiratie kan dienen. Het is zeker niet mijn bedoeling om hiermee te zeggen dat dit de juiste manier van werken is. Ook ik ben mens en ook ik maak fouten of pak dingen niet handig aan. Probeer het objectief te lezen en datgene eruit de halen wat waardevol voor je is. Hetgeen wat minder voor jou van toepassing is laten we voor wat het is.”Ik ben natuurlijk wel onwijs geïnteresseerd in jouw feedback en ik waardeer het enorm als je na het lezen van dit blog een reactie onderin wilt achterlaten. Mocht het waardevol voor je zijn geweest, voel je ook vrij om het te delen op jouw favoriete social media.

En dan nu de inhoud in. Zit je al een tijdje te denken om een start te maken met DevOps? Of wellicht ben je onlangs begonnen met de DevOps reis maar loop je vast en zie je door de bomen het bos niet meer. Dan is dit blog zeker iets voor jou!

Met grote regelmaat krijg ik de vraag: ”Waar begin je dan met DevOps?” Moet je eerst beginnen met het team? Of eerst bij management? Of wellicht eerst de processen aanpakken? Of toch misschien beginnen met Cloud of het inrichten van CI/CD? Of misschien toch maar eerst beginnen met testautomatisering? Zoveel keuzes en veel mensen hebben daardoor keuzestress. Ze hebben echt geen idee waar te beginnen, want het is ook zoveel wat er nog allemaal verbetert kan worden.

Daarom laat ik in dit blog in de volgende 6 simpele stappen zien hoe je naar concrete acties komt:

Stap 1:
Neem een gemotiveerd team.

Stap 2:
Kies 1 pipeline welke het team het meest gebruikt.

Stap 3:
Maak samen met het team een VSM van deze pipeline.

Stap 4:
Prioriteer alle verbeteringen die uit de VSM naar voren zijn gekomen.

Stap 5:
Vertaal de verbeteringen naar user stories en plaats deze op de backlog zodat we in het bestaande werkproces terecht komen.

Stap 6:
Pak minimaal 1 verbetering per sprint op.

Deze stappen staan in dit blog verder toegelicht.

Stap 1

Wat ik meestal adviseer (maar dat ligt natuurlijk wel aan de context): begin met één team. Heb je meerdere teams in de organisatie? Laat die allemaal even voor wat het is en begin met “maar” één team. Babysteps! Met kleine stapjes werken aan verbeteringen en optimalisatie. Een baby kan ook niet meteen lopen. Eerst voorzichtig recht overeind staan, ergens aan vast houden en van daaruit kleine stapjes zetten en de eerste stapjes zonder ergens aan vast te houden. Het is vallen en opstaan; ook bij die baby die leert lopen.

Als je hebt besloten om met een team aan de slag te gaan, pak wel het team dat het meest gemotiveerd is. Want dat versnelt de successen die gehaald gaan worden. Ook als je een team hebt waar weerstand zit, is dit blog waardevol voor jou. Dit helpt ook in de nabije toekomst als je met andere teams aan de slag gaat. Je hebt immers al bewezen dan het werkt!

Stap 2

Ok, en nu? Je hebt 1 team gekozen. Een team met enthousiaste en gemotiveerde collega’s. Zij willen wel een start maken met DevOps. Maar dan, waar begin je dan bij dat team?

Een VSM, je begint met het maken van een VSM. VSM staat voor Value Stream Mapping en komt van origine uit Lean. Het is het visueel maken van een proces om vervolgens te bepalen waar de vertragingen zitten. De bottlenecks, de wachttijden, de overdrachtsmomenten, de doorlooptijden en de effectieve uitvoeringstijden. Een VSM is een zeer waardevol middel om; 1, het inzichtelijk te maken waar de pijnpunten zitten, maar 2, ook om het gesprek op gang te brengen.

Door juist met 1 team te beginnen, haal je onwijs veel waardevolle informatie uit het gesprek. Waar loopt het team tegen aan qua besluitvorming, qua bedrijfsprocessen, qua bureaucratie? Allemaal zaken waar ook waarde te halen valt.

Stap 3

Maar goed, dat zijn zaken voor een later moment, nu eerst de VSM maken. Mocht het team een pipeline hebben, of zelfs meerdere pipelines voor hun producten, kies er dan één. De pipeline welke zij het vaakst gebruiken. Dat is het startpunt voor de VSM. Ok, je hebt het team, en je hebt de pipeline, nu gaan we daadwerkelijk aan de slag met de VSM.

Op het moment van het schrijven van dit blog zitten we in een lockdown vanwege COVID-19. De meeste mensen werken vanuit huis. Dit kan een voordeel zijn of een nadeel, maar dat laat ik voor nu achterwege. Echter betekent dit wel dat we de VSM “remote” moeten doen. De teamleden zitten thuis achter de computer en dat betekent dat we andere tools moeten gebruiken om de pipeline visueel uit te werken. Dit keer geen fysiek whiteboard met stickies, maar een digitaal whiteboard met digitale stickies.

Ik ben ondertussen een groot fan geworden van MIRO. Wat mij betreft is dit DÉ tool voor online samenwerken. Voor brainstorm sessies, voor creatieve sessies, voor retrospectives en nog veel meer. En dus ook voor het online uitwerken van een VSM. Wat ga je nu allemaal verwerken in de VSM? In het begin zie ik dat een developer “iets” gaat inchecken vanaf zijn/ haar laptop, of andere werkplek. Dat “iets” is meestal een regel code of meerdere regels code.

Het kan bij voorbeeld een feature zijn of een aanpassing. Anyways, de developer checkt iets in. Dat is het startpunt van de VSM. Zodra datgene is ingecheckt moet de vraag zijn: “Wat is de handeling of actie die direct daarna plaatsvindt?” Zorg ervoor dat dit klein en concreet is. Dit is één transactie, één handeling en geen bundeling van transacties of handelingen. 

Je wilt dit super gedetailleerd hebben. Deze handeling of transactie, is dat dan een handmatige actie of een geautomatiseerde actie? Als het een handmatige actie is dan maken we dat blokje in MIRO rood, zodat we meteen visueel hebben gemaakt dat het een handmatige actie betreft.

Voordat we verder gaan met de volgende handeling, willen we een aantal dingen weten. Wordt er iets aangeroepen? Wordt er een call naar externe systemen gedaan met behulp van bijvoorbeeld een API? Want ook dat willen we inzichtelijk hebben. Als dat het geval is, dan wordt dit wederom in de VSM verwerkt. Maar alleen benoemen dat er een uitstap wordt gemaakt naar een extern systeem. Voor de rest doen we daar nog niks mee.

We gaan weer terug naar het eerste blokje nadat de developer het heeft ingecheckt, het rode blokje. Wat is de eerstvolgende handeling of transactie die komt na dit rode blokje? Is dit weer een handmatige actie, of is dit een geautomatiseerde actie? Als het een geautomatiseerde actie is, dan maken we een blauw blokje aan. Nu begin je de eerste contouren te zien van het proces van de pipeline. Een icoontje met een laptop, een rood blokje en een blauw blokje.

Wat we nu willen weten is wat de transactietijden zijn, de doorlooptijden en de wachttijden. Bij elk blokje heb je een transactietijd. Dit is de tijd die nodig is om te verwerken. Dit kan het aanroepen van een API zijn, het draaien van één of meerdere tests; het maakt niet zoveel uit. We willen weten hoeveel tijd er nodig is om datgene te verwerken voordat het naar een volgend blokje gaat. Deze tijd mag een schatting zijn. Dit hoeft niet in seconden. Een schatting in minuten is voor nu voldoende.

Nu we deze transactietijd weten, willen we ook weten wat de wachttijd is van het eerste blokje naar het tweede blokje. Het kan zijn dat er geen wachttijd is, maar het kan ook zo zijn dat er een time-out is ingebouwd. We willen in ieder geval weten wat de wachttijd is, in het geval dat die er is. Als laatste willen we de doorlooptijd weten. De doorlooptijd is inclusief de transactietijd en wachttijd.

Dit proces, van het visueel maken van de handelingen met de wachttijden, de transactietijden en de doorlooptijden gaan we helemaal af maken tot en met de productieomgeving. We willen namelijk precies weten welke handelingen en transacties (zowel handmatig als geautomatiseerd) er nodig zijn om die regel code(s) in de productie te laten landen. Want, als het goed is, gaan die regels codes waarde leveren aan de klant/gebruiker.

Deze exercitie noemen we een VSM: “het inzichtelijk en visueel maken van een proces”, en deze keer is dat een pipeline.

Stap 4

Maar hoe nu verder dan? Je wilt namelijk voorkomen dat het in een lade verdwijnt en stof gaat happen, dus eigenlijk wil je borgen dat het niet verloren gaat en dat het landt in het bestaande werkproces van het team.

Je gaat nu samen met het team bepalen waar ze het meeste last van hebben, en dit is makkelijk want de tijden staan erbij en we hebben inzichtelijk gemaakt waar de handmatige acties zitten en waar de geautomatiseerde acties zitten. Hetgeen waar ze de meeste last van hebben zal hoogstwaarschijnlijk een handmatige actie zijn. Dit is verbetering #1.

Vervolgens identificeren we alle verbeterpunten en schrijven we deze op. Het is het handigst om deze meteen op te schrijven als user story en op de backlog te plaatsen, lees het bestaande werkproces van het team. Want we willen voorkomen dat deze exercitie vervolgens in iemands lade terechtkomt. Dus meteen de koe bij de hoorns pakken en alle verbeteringen op de backlog als user story plaatsen.

Stap 5

Houd bij het plaatsen van deze verbeteringen meteen rekening met de prioriteit. Waar heeft het team het meeste last van, want dat is de user story die bovenaan komt te staan. 

Nu de VSM is gemaakt en alle verbeteringen op de backlog als user story zijn geplaatst, ben je wel een 2 of 3 uur verder. Tijd om dit te vieren! Jullie hebben middels de eerste stap gezet in het omarmen van de DevOps manier van werken. Jullie hebben inzichtelijk gemaakt waar de verbeteringen liggen en aangegeven welke het belangrijkst zijn om op te pakken. Jullie hebben ook geborgd dat het de komende periode wordt opgepakt, want het staan op jullie backlog met de juiste prioriteit.

Stap 6

Ok, de laatste stap! Jullie hebben een VSM gemaakt, verbeterpunten geïdentificeerd en deze ook vervolgens de juiste prioriteit meegegeven. Het allerbelangrijkste komt nu, er daadwerkelijk iets mee doen.  Het werk oppakken en dingen gaan verbeteren, optimaliseren en achterstallig onderhoud wegwerken. Dit is ook DevOps mensen; kleine dingetje oppakken om uiteindelijk veel waarde aan de klant / gebruiker te kunnen leveren.

Om te borgen dat de verbeteringen daadwerkelijk worden opgepakt, maak een expliciete afspraak met het team over hoeveel en hoe vaak er verbeteringen worden opgepakt. Mijn advies, dit moet structureel onderdeel zijn van de werkzaamheden. Dus niet eens in de zoveel tijd, nee, continu! Elke sprint, er van uit gaan dat je volgens Scrum werkt, in elke sprint staat er wel een paar stories die verbeteringen opleveren of technical debt verminderen. Minimaal 1 per sprint, maar liever een paar.

Werk je Kanban of scrumban, zorg er dan voor dat minimaal 1 workitem van de WIP een verbetering is.

Zo dan, nog even op een rijtje:

Stap 1:
Neem een gemotiveerd team.

Stap 2:
Kies 1 pipeline welke het team het meest gebruikt.

Stap 3:
Maak samen met het team een VSM van deze pipeline.

Stap 4:
Prioriteer alle verbeteringen die uit de VSM naar voren zijn gekomen.

Stap 5:
Vertaal de verbeteringen naar user stories en plaats deze op de backlog zodat we in het bestaande werkproces terecht komen.

Stap 6:
Pak minimaal 1 verbetering per sprint op.

Dit was hem dan weer voor dit blog. Ik hoop dat je hier iets aan hebt gehad. Mocht je vragen of opmerkingen hebben, laat het me weten.
Als het je wat heeft gebracht, bijvoorbeeld nieuwe inzichten, voel je vrij om hem te delen op Social Media.