Delta-NHet belang van meten in DevOps – sneller van idee naar gebruiker
De organisatie DevOps Research and Assessment (DORA) heeft onderzoek gedaan naar meten en visualisatie, en geconcludeerd dat er op dit gebied een viertal aspecten zijn die een belangrijke rol spelen om succesvol in DevOps te zijn:
  • Visual management
  • Work in Progress (WIP) limieten toepassen
  • Monitoring
  • Notificeren bij fouten

In een serie van vier blogs zal ik deze onderdelen behandelen. Het vorige blog ging over Visual management. Dit blog gaat over het toepassen van Work in Progress (WIP) limieten.

HET BELANG VAN METEN IN DEVOPS

Waarom is WIP van belang

HET BELANG VAN METEN IN DEVOPSWanneer er teveel werk is en er te weinig mensen zijn om dit werk te doen, dan is het een natuurlijke reactie vanuit “het management” om aan team leden te vragen om aan meerdere taken tegelijkertijd te werken. Helaas is het resultaat tegenovergesteld, door aan meerdere taken tegelijkertijd te werken ga je minder snel iets afkrijgen. Daarnaast heeft het een negatief effect op het team blijkt uit wetenschappelijk onderzoek.

Wat je het beste kunt doen in zo een geval is het werk prioriteren en het team laten werken aan een beperkt aantal, hoge prioriteit, taken zodat deze ook echt afgerond worden voordat er iets nieuws wordt gestart.

Het beperken van de hoeveelheid werk waar een team tegelijkertijd aan werkt (Work in Progress (WIP)) kent zijn oorsprong in productiebedrijven. Het is een belangrijk onderdeel van de ‘just-in-time’-filosofie die Toyota heeft ontwikkeld als onderdeel van zijn productiesysteem. Wat hiermee wordt bedoeld is dat fabrieken geen grote hoeveelheden voorraad aanhouden. Wanneer een klant een bestelling plaatst zorgt men ervoor dat de benodigde onderdelen op het juiste moment gemaakt en geleverd worden Je zou verwachten dat dit langer duurt, maar als het goed wordt geïmplementeerd (er zijn een aantal principes en werkwijzen die gevolgd moeten worden) krijg je snellere doorlooptijden, hogere kwaliteit en lagere kosten.

Daar waar het gaat om software ontwikkeling is de voorraad niet zichtbaar. Er is geen fabriekshal waar je ziet dat werk zich opstapelt omdat een volgende stap nog niet begonnen kan worden. Je kunt de voorraad wel op een eenvoudige manier zichtbaar maken door deze op een geeltje te schrijven en op een bord te plakken. Als je op een agile manier werkt kennen we bijvoorbeeld het Kanban bord of het Scrum bord. Je kunt een Kanban bord maken waarbij je de verschillende stappen in het software ontwikkelproces in kolommen zet. Denk hierbij aan bijvoorbeeld “Analyse”, “Ontwikkelen” , “Testen”, “Release naar Productie” en “Afgerond”.
(Source: David J. Anderson and Dominica DeGrandis, Kanban for IT Ops, training materials for workshop, 2012.)

Wanneer je al het werk dat je doet op het bord hebt staan, kun je elke dag dat je aan een taak werkt een stip op het geeltje zetten. Op deze manier kun je direct zien hoeveel dagen er aan een taak of onderdeel is gewerkt. Dit geeft inzicht in de doorlooptijden op dit moment (vandaag).

De volgende stap is het introduceren van WIP limieten. Voor elke kolom gaan we een limiet stellen, bijvoorbeeld maximaal 2 taken in “Ontwikkelen” en maximaal 2 taken in “Testen”. Op het moment dat we een derde ontwikkel taak willen starten kan dit niet, er moet eerst een ontwikkel taak naar test worden gezet voordat je een nieuwe kunt starten. In plaats van het starten van een ontwikkel taak kun je een test taak oppakken of meehelpen met één van de twee ontwikkel taken zodat er weer ruimte komt om een nieuwe ontwikkel taak op te pakken. Als je dit goed toepast heb je een echt Kanban bord.

Hoe hoog je de WIP limiet moet zetten hangt onder andere af van de omvang van het team en de grootte van de taken. Stel dat je 6 ontwikkelaars hebt die pair programming doen mag je niet aan meer dan 3 ontwikkel taken tegelijkertijd werken. Het werken aan meerdere taken tegelijkertijd is ervoor verantwoordelijk dat productiviteit sterk afneemt, trap niet in deze valkuil.

Het vasthouden aan WIP limieten kan (en zal) pijnlijk zijn. Het komt vaak voor dat teamleden inactief zijn omdat ze niet kunnen werken aan éénn van de taken, omdat ze wachten op het voltooien van andere taken Hoe verleidelijk het ook mag zijn, verhoog de WIP limieten niet. Werk in plaats daarvan aan het verbeteren van uw processen om de factoren aan te pakken die bijdragen aan deze vertragingen. Als je bijvoorbeeld wacht op een omgeving om het werk te testen, kun je het team dat de omgevingen voorbereidt helpen het proces te verbeteren of te stroomlijnen.

Dominica DeGrandis, een van de toonaangevende experts op het gebied van toepassen van Kanban in DevOps merkt op dat het vasthouden aan WIP limieten buitengewoon krachtig is omdat het één van de weinige middelen is om de doorlooptijd in Software ontwikkeling te beïnvloeden.

Het gevaar van overdrachten en wachtrijen

HET BELANG VAN METEN IN DEVOPSHet probleem van grote wachtrijen wordt verergerd als er veel overdrachten zijn. Onderstaande figuur toont hoe groot de wacht tijd is ten opzichte van hoe druk iemand het heeft. Hoe drukker iemand het heeft hoe langer het duurt voordat een taak wordt opgepakt en afgerond. Een eenvoudige aanpassingen kan hierdoor dagen of soms wel weken duren. Doordat iemand 100% vol zit kan hier niet direct mee gestart worden.

HET BELANG VAN METEN IN DEVOPS
Source: Kim, Behr, and Spafford, The Phoenix Project, ePub edition, 557

In de figuur hiernaast staat op de x-as het percentage dat iemand bezet is, op de y-as staat de wachttijd (of beter gezet, de lengte van de wachtrij). Bij een bezetting van meer dan 80% zie je de wachttijd significant stijgen. Voor wie The Phoenix project heeft gelezen, dit is het moment dat Bill en het team zich realiseren wat het effect is op de doorlooptijd.

In The Phoenix project wordt uitgelegd dat wachttijd de uitkomst is van het percentage bezet dat iemand is gedeeld door het percentage beschikbaar. Dus stel dat iemand voor 50% bezet is (en dus 50% beschikbaar) dan is de wachttijd 1 uur. Oftewel, na 1 uur wordt de volgende taak opgepakt. Stel nu dat iemand 90% bezet is, dan is de wachttijd 9 uur (90 procent / 10 procent). Oftewel, 9 keer langer dan wanneer iemand 50% bezet is. En als er 7 stappen zijn om een taak af te ronden en dit geldt bij elke stap dat is er een wachttijd van 7 (stappen) * 9 uur (wachttijd per stap) = 63 uur (oftewel 8 werkdagen). En als de aanpassing zelf 1 uurtje in beslag neemt is de doorlooptijd van deze aanpassing 64 uur!

Maar hoe helpt het instellen van WIP limieten hierbij? De WIP limiet maakt inzichtelijk waar de problemen liggen voor het afronden van een taak. De WIP limiet kan ervoor zorgen dat iemand niets kan doen voordat een collega klaar is. Alhoewel het verleidelijk is om dan nog maar een taak op te pakken (je kunt immers beter iets doen dan niets doen) is het veel beter om te kijken waar er vertraging of hulp nodig is en dit op te lossen voordat je een nieuwe taak oppakt. Een nog slechtere vorm van aan meerdere taken tegelijkertijd werken is wanneer iemand in verschillende teams aan verschillende producten werkt. Dan komt namelijk ook het prioriteren tussen producten in het gedrang.

Samenvattend: Zoals David Anderson, auteur van Kanban: Successful Evolutionary Change for Your Technology Business, quipped, “Stop starting. Start finishing.” Maak eerst iets af voordat je iets nieuws begint!

Veelgemaakte fouten

HET BELANG VAN METEN IN DEVOPSBelangrijk om in het achterhoofd te houden is dat het doel van WIP limieten is om doorstroming te krijgen en de kwaliteit te verhogen. Als het effect van het toepassen van WIP limieten niet is dat een idee sneller bij de eindgebruiker beschikbaar komt, of wanneer je merkt dat de kwaliteit omlaag (of niet omhoog) gaat, dan is de gestelde WIP limiet niet goed.

Er zijn een aantal veelgemaakt fouten bij het toepassen van WIP limieten:

  • Allereerst is het van belang om het gehele proces van idee tot aan beschikbaar zijn voor de eindgebruiker te visualiseren, niet alleen het deel waar het team aan werkt. Als je dit namelijk niet doet zie je niet waar de echte bottlenecks zitten. Hierdoor kun je wel eens de verkeerde verbetering doorvoeren, of een verbetering doorvoeren die weinig resultaat biedt omdat het echte probleem verderop (of eerder) in het proces zit.
  • Zorg ervoor dat de WIP limieten niet te hoog zijn. Als teamleden nog steeds aan meerdere taken tegelijkertijd werken is dit een sterk signaal dat de WIP limiet te hoog is.
  • Pas je WIP limiet niet aan als mensen niets te doen hebben, zorg ervoor dat ze collega’s gaan helpen zodat de flow op gang komt of blijft.
  • Als het eenvoudig is om aan de WIP limiet te voldoen, maar ze dan lager. Het doel van WIP limieten is om problemen inzichtelijk te maken.
  • Als er veel verschillende stappen zijn op het bord in het proces van idee tot aan beschikbaar stellen voor de eindgebruiker, kijk dan hoe je dit kunt vereenvoudigen door het proces te vereenvoudigen.

WIP limieten moeten inzichtelijk maken wat een hogere doorstroming tegenhoud. Het opvolgen en verwijderen van deze obstakels zijn essentieel, als je dit niet doet dan verandert er ook niets.

Hoe kun je verbeteren

HET BELANG VAN METEN IN DEVOPSBegin met het visualiseren van al het werk. Zet vervolgens WIP limieten die passen bij de capaciteit van het team. Zorg ervoor dat de WIP limiet nooit hoger is dan het aantal mensen data an een bepaalde process stap bijdraagt (heb je 4 ontwikkelaars? Dan is de WIP voor ontwikkelaars 4. Heb je 2 testers? Dan is de WIP voor testen 2). Je moet voorkomen dat mensen aan meer dan 1 taak tegelijkertijd moeten werken. Start vervolgens met werken en kijk hoe het loopt.

Focus op het starten met toepassen van WIP limieten, en op basis van de ervaringen die je opdoet kun je de limieten strakker zetten of minder strak. Richt je vooral op het inzichtelijk maken van problemen en los deze op. Het doel is het vergroten van flow, dus begin met het meten van bijvoorbeeld doorlooptijden. Leg vast wanneer er met werk wordt begonnen en wanneer het wordt opgeleverd. Leg dit gedurende langere periode vast, analyseer de data continue en zie of de doorlooptijden inderdaad verkort zijn en of de flow verbeterd is.

Een volgende stap is om het aantal stappen in het proces te verkleinen. Elke handoff zorgt voor wachttijd en zoals hiervoor beschreven is de impact hiervan zeer negatief. Hoe kun je het aantal handoffs verkleinen? Bijvoorbeeld door het vereenvoudigen en automatiseren van taken. Heb je dat gedaan, verlaag dan weer de WIP limieten. Het is een continue proces, blijf dit dan ook herhalen!

Manieren om WIP limieten te meten

WIP limieten is iets dat je toepast en niet zozeer meet, maar het is belangrijk voor het team om manieren te vinden om te verbeteren. Een aantal goede vragen die je tijdens bijvoorbeeld een retrospective kunt stellen is:

  • HET BELANG VAN METEN IN DEVOPSWeten we wat de doorlooptijd is voor onze gehele value stream (dus van idee tot aan beschikbaar stellen voor de eindgebruiker)?
  • Zijn er nog manieren om de flow te verbeteren en dus de doorlooptijd te verkorten?
  • Komen door het toepassen van onze WIP limieten problemen naar voren waardoor we de doorlooptijd niet kunnen verkorten?
  • Wat doen we aan deze obstakels?

Conclusie

Alhoewel de verleiding groot is om als manager of als ontwikkelaar aan meerdere taken tegelijkertijd te werken omdat je denkt dat je dan sneller bent, wetenschappelijk onderzoek heeft aangetoond dat juist het tegenovergestelde waar is. Doorlooptijden worden groter en de “werkvoorraad” stijgt. In plaats van meer taken oppakken moet je naar de overige stappen in het proces kijken en daar waar het nodig is meehelpen zodat er weer ruimte ontstaat om een volgende taak op te pakken.

Herken je één of meer gemaakte fouten en wil je hier mee aan de slag? Denk dan aan de genoemde manieren om te verbeteren. Mocht je hier meer over willen weten neem dan contact met mij op.

Marcel Groennou, DevOps Consultant