De organisatie DevOps Research and Assessment (DORA) heeft onderzoek gedaan naar meten en visualisatie, en geconcludeerd dat er op dit vlak een viertal aspecten zijn die een belangrijke rol spelen om succesvol in DevOps te zijn:
- Visual management
- Gebruik maken van Work in Progress (WIP) limieten
- Monitoring
- Notificeren bij fouten
In een serie van vier blogs zal ik deze onderdelen behandelen. Dit blog gaat over Visual management.
Visualisatie
Vanuit Lean is het gebruikelijk om belangrijke informatie over verschillende processen weer te geven op een plek waar iedereen in de organisatie dit kan zien (en vooral ook de teamleden zelf). Wanneer je de informatie die je laat zien goed organiseert kun je een gedeeld beeld creëren van waar je als team staat met het werk dat je aan het doen bent. Het geeft ook inzicht waar je tegen aanloopt als team, wat de voortgang tegenhoud en maakt het dus ook mogelijk deze obstakels te identificeren en weg te nemen.
Binnen een software ontwikkel team zijn er vele visualisaties mogelijk, maar de meest voorkomende zijn:
- Borden met daarop Story boards of Kanban boards. Dit kan zowel fysiek zijn (door middel van geeltjes) als digitaal zijn. De borden geven weer aan welke items een team werkt en wat de voortgang is.
- Burn-up of Burn-down grafiek, deze geven aan hoeveel werk al gedaan is of hoeveel werk er nog gedaan moet worden in bijvoorbeeld een sprint.
- Informatie over de status van de build, bijvoorbeeld door een stoplicht (groen of rood) of een status melding welke wordt weergegeven.
- Informatie over de status van de Deployment, bijvoorbeeld welke naar welke omgeving welke build is uitgerold en of deze succesvol is geweest.
- Informatie omtrent de status van de applicatie in productie (bijvoorbeeld aantal requests ontvangen de afgelopen 15 minuten, gegevens omtrent latency, aantal 404 en/of 500 errors op de belangrijkste pagina’s).
Door het verzamelen en weergeven van deze informatie wordt er bijgedragen aan een betere kwaliteit en performance van het team.
Het doel van visual management is het verzorgen van snelle en eenvoudig te begrijpen feedback over de belangrijkste onderdelen van de geleverde oplossing, met als doel in geval van problemen snel te kunnen schakelen zodat deze effectief opgepakt kunnen worden. Om dit te bereiken moet er aan een aantal voorwaarden worden voldaan:
- Het geeft de informatie weer die het team belangrijk vindt en op basis waarvan het team actie onderneemt. Het heeft geen zin om bijvoorbeeld informatie omtrent de build status weer te geven als een team niet actief aan de slag gaat als een build rood kleurt.
- De informatie is eenvoudig (in een oogopslag) te begrijpen. Wanneer een uitgebreide studie nodig is om te zien of er een probleem is dan schiet je het doel voorbij.
- Het heeft informatie weer die relevant is voor het werk van het team. Ook al is het belangrijk zoveel mogelijk informatie te verzamelen, je moet alleen die informatie die relevant is tonen. Als je dit niet doet krijg je teveel informatie en voor je het weet gaan mensen niet meer actief op het bord kijken.
- De informatie actueel houden is onderdeel van het dagelijks werk. Daar waar de informatie niet digitaal is en automatisch wordt verzameld, moet het team er zelf voor zorgen dat de informatie wordt bijgewerkt. Denk aan een burn-up of burn-down chart die wordt bepaalt op basis van taken en story’s die op done staan. Als teamleden dit niet nauwgezet doen is de getoonde informatie niet waardevol.
Veel gemaakt fouten
Het belangrijkste omtrent visualisatie is dat de teams de getoonde informatie relevant vinden en daadwerkelijk er iets doen met de getoonde informatie. Daardoor wordt de getoonde informatie ook onderdeel van het dagelijks werk en gebruikt om problemen te zien en op te lossen. Enkele veel gemaakte fouten zijn echter:
- De getoonde informatie is gemaakt door het management en het team is hierbij niet vetrokken. Als dit het geval is zal een team weinig aandacht besteden aan de getoonde informatie. Sterker nog, de kans is groot dat teams (bewust of onbewust) de weergegeven informatie proberen te beïnvloeden. Met name omdat de informatie niet als waardevol wordt beschouwd en teams deze informatie in het geheel niet gebruiken.
- De getoonde informatie is te complex, moeilijk te begrijpen of geeft geen aanleiding tot actie. Goed bedoelde grafieken, of interessante opsomming van informatie kunnen het doel eenvoudig voorbij schieten. Informatie hoeft niet real-time bijgewerkt te worden, ook eenmaal per dag handmatig kan als het maar het doel dient.
- De getoonde informatie evolueert niet. Het kopiëren van een bord van een ander team heeft geen toegevoegde waarde. Je moet kijken welke informatie jou team nodig heeft. Gedurende de maanden zal het team zich ontwikkelen, het belangrijk dat het bord mee-ontwikkelt. Als dit niet gebeurd wordt de informatie minder waardevol en kan het zijn dat deze zelfs helemaal niet meer wordt gebruikt.
- Niet het echte probleem oplossen welke op het bord getoond wordt. Wat vaak voorkomt is dat de build faalt, en dus rood wordt, en dat dan alleen de huidige error wordt verholpen. Maar wat als dit dagelijks of wekelijks gebeurd. Gaan we dan het echte probleem oplossen?
Hoe kunnen we verbeteren?
Breng in kaart waar je nu staat met de visualisatie. Zoek een manier om de belangrijkste informatie over de huidige staat van het werk en de ondersteunende processen te tonen. Toon alleen die informatie die aan voorgaande eisen voldoet.
Neem de visualisatie borden mee als onderdeel van de retrospective en stel jezelf als team de volgende vragen:
- Geven de borden nog steeds de informatie die we nodig hebben?
- Is de informatie actueel?
- Reageert het team ook op basis van de getoonde informatie?
- Heeft de getoonde informatie en de daaropvolgende ondernomen actie ook geleid tot een daadwerkelijke verbetering richting een doel dat we als team hebben?
- Weet iedereen welke doelen het team heeft?
- Als ik nu naar het visualisatie bord kijk, worden er dan metrics getoond omtrent processen die voor mij relevant zijn?
Als het antwoord op een van deze vragen nee is ga hier dan dieper op in.
- Kunnen we de wijze waarop de informatie getoond wordt veranderen?
- Kunnen we de informatie beter verwijderen omdat het niet meer bijdraagt aan een doel?
- Moeten we nieuwe informatie tonen?
Conclusie
In DevOps is het visualiseren van informatie belangrijk, het geeft immers input voor verbeteringen en maakt snel inzichtelijk of er verbeteringen noodzakelijk zijn. Kijk hoe hier binnen jouw organisatie mee omgegaan wordt. 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 meer willen weten neem dan contact met mij op.
