Wat is DevOps en 3 voordelen ervan
Steeds vaker krijg ik de vraag of ik kan helpen bij Agile teams die DevOps willen gaan werken. Daarom zet ik graag een aantal voordelen ervan op een rij te voor managers, transformatie begeleiders en team leads die nog minder bekend zijn met DevOps.
Wat betekent DevOps
DevOps is een samenvoeging van twee Engelse woorden: development en operations. Tot een jaar of 10 geleden werkten de meeste software ontwikkel teams gescheiden van operationele teams. Software development teams focusten zich op het ontwikkelen van nieuwe producten, services en features. Het operationele team of kortweg ops team hield zich bezig met eventuele foutmeldingen of bugs en het monitoren van de operationele performance van software..
DevOps voegt die werelden samen. Dat wil niet zeggen dat je team twee keer zo groot wordt. Het betekent wel dat het team dat een product of service ontwikkelt, ook zorgt draagt voor de operationele werking ervan inclusief het oplossen van foutmeldingen, bugs etc. Ik leg je graag uit wat daar de businesswaarde van is aan de hand van drie voordelen.
1. Problemen sneller opgelost
Het klinkt allemaal mooi, een apart team met 100% focus op het oplossen van allerlei oprationele problemen. Maar in de praktijk is dat niet altijd zo. Vaak heeft een operationeel team te weinig kennis van het product om foutmeldingen op te lossen. In veel gevallen komt een issue alsnog op de backlog van het development team terecht.
In tegenstelling tot het software development team dat het product zelf ontwikkeld heeft. Dit team heeft alle kennis in huis om een probleem snel en goed op te lossen. De root cause analysis kost ook minder tijd. Daarmee is de klant sneller van het probleem af en heeft de organisatie minder tijd = geld uitgegeven bij het oplossen van het probleem.
Hoe zit het dan met kennisoverdracht? Natuurlijk doet een goed development team rond de release van een nieuw product een kennisoverdracht met het ops team. Maar vrijwel altijd beheren ops teams een hele rits aan applicaties. Die lang niet allemaal evenveel problemen kennen. Hierdoor zakt kennis weg en kun je de kennisoverdracht deels als "waste" beschouwen.
In de ideale situatie heeft een DevOps team het testen en monitoren end-2-end geautomatiseerd. Het automatiseren van testen en monitoren helpt om tijdens het ontwikkelen sneller achter code foutjes te komen en wanneer een product gebruikt wordt door de klant, eventuele bugs al te ontdekken voordat de klant ze ervaart.
De businesswaarde voor de organisatie is dus de tijdsbesparing en klanten weer sneller een goede ervaring kunnen geven.
2. Hoe waardevol is het oplossen van het probleem
Meer dan eens heb ik bij opdrachtgevers gewerkt waar operationele teams werden afgerekend op de tijd dat een ticket of issue open stond. Er werd dus niet naar kwaliteit businesswaarde gekeken maar alleen naar of een probleem binnen de afgesproken tijd was opgelost.
Niet alle problemen die gemeld werden waren even groot of belangrijk. Maar wanneer je daar niet op stuurt, kom je daar ook niet achter. Bij DevOps worden PO en team gedwongen om keuzes te maken. Je kunt je tijd maar één keer besteden. Je wilt er dus zeker van zijn dat waar je je tijd aan besteed het meest waardevolle is.
In veel gevallen ga je dan of het gesprek aan of je duikt in de data om te zien hoe groot die waarde is. Alleen zo weet je of je gepland werk aan de kant moet schuiven of niet. Wanneer je er dan achter komt dat een grote groep klanten NU iets niet kan wat veel gebruikt is of de verkoop blokkeert dan maak je tijd, is het een knop in de app die 10x per maand gebruikt wordt, dan kan het wellicht best even wachten.
De businesswaarde zit dus in het achterhalen van de businesswaarde en niet klakkeloos achter ieder issue aan gaan rennen omdat iemand roept dat het super-mega-belangrijk is.
3. Hogere kwaliteit: "eat your own dog food"
Bij één van mijn opdrachtgevers waren een aantal scrum teams nog niet zo bedreven met scrum. Het team had ook een aantal beginnende developers wat de kwaliteit van code en het testen van die code niet altijd ten goede kwam. Het gevolg was dat er veel bugs gemeld werden na een release.
Het team had hier zelf geen last van want issues werden normaliter opgepakt door het ops team. Door tekort aan kennis bij het ops team duurde het ook lang voordat issues opgelost werden, als ze al opgelost werden. Tot het moment dat DevOps ingevoerd werd en developers geconfronteerd werden met niet goed werkende code die ze zelf ontwikkeld hadden. Binnen de korste keren werd peer-reviewing ingevoerd, werden en geautomatiseerde testen opgezet en werd er ook de performance van de productie software realtime gemonitord.
De Product Owner en het team wilde die last niet dragen. Door de pijn te beleggen bij de groep die de pijn het best op kon lossen werd er binnen een aantal sprints volgens DevOps wijze veel winst geboekt. Het "eat your own dog food" principe werkte feilloos.
De businesswaarde zit in dit geval in teams hun eigen issues op laten lossen, waardoor er meer focus komt op hoge kwaliteit en geautomatiseerd testen. Hierdoor wordt er onder de streep veel minder tijd besteed aan het oplossen van bugs omdat die er bijna niet meer zijn. Dat geeft weer meer ruimte voor innovatie en echte software product verbeteringen en daarmee echte klantwaarde.
Ik hoop dat ik je in dit artikel heb uit kunnen leggen wat DevOps is, en wat de businesswaarde van een DevOps team is. Heb je hulp nodig bij de transitie van waterval of scrum of een andere smaak naar DevOps, dan help ik je daar uiteraard graag bij!
