Wat is DevOps? 3 voordelen voor organisaties

Regelmatig krijg ik de vraag of ik Agile teams kan begeleiden bij de overstap naar DevOps. Maar wat verandert er eigenlijk wanneer ontwikkelaars ook verantwoordelijkheid nemen voor het beheer van hun software? En welke voordelen levert dat op voor klanten en de organisatie?

 

 

Wat betekent DevOps

DevOps is een samenvoeging van twee Engelse woorden: development en operations. Tot een jaar of 10 geleden werkten de meeste ontwikkelteams gescheiden van operationele teams. Ontwikkelteams 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 prestaties 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 zorg 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.

 

 

Wat is het verschil tussen Scrum en DevOps?

Scrum is een framework dat teams helpt complexe producten en services iteratief te ontwikkelen en continu waarde te leveren. DevOps richt zich op de samenwerking, cultuur en technische werkwijzen die nodig zijn om software betrouwbaar te ontwikkelen, uit te rollen en te beheren.

Scrum en DevOps sluiten elkaar niet uit. Een Scrum Team kan DevOps-principes toepassen door bijvoorbeeld testen, deployment, monitoring en operationele feedback in het dagelijkse werk te integreren.

 

 

1. Problemen sneller opgelost

Het klinkt allemaal mooi, een apart team met 100% focus op het oplossen van allerlei operationele 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 heeft ontwikkeld. 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 en geld besteed 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-to-end geautomatiseerd. Het automatiseren van testen en monitoren helpt om tijdens het ontwikkelen sneller achter codefouten te komen en wanneer een product gebruikt wordt door de klant, eventuele bugs al te ontdekken voordat de klant ze ervaart.

De businesswaarde zit in kortere oplostijden, lagere operationele kosten en minder verstoring voor klanten.

 

 

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 of 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 waaraan je je tijd besteedt 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 winst zit in bewust prioriteren op klant- en businesswaarde, in plaats van ieder incident automatisch voorrang te geven 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 waardoor de kwaliteit van code en het testen onder druk kwamen te staan. Het gevolg was dat er meer bugs gemeld werden na releases.

Het team had hier zelf geen last van want issues werden normaliter opgepakt door het Ops-team. Door tekort aan kennis bij dat Ops-team duurde het ook lang voordat issues opgelost werden, als ze al opgelost werden.

Tot het moment dat het Scrum-team DevOps ging toepassen en zelf verantwoordelijk werd voor het oplossen van die bugs. Vanaf dat moment ging de waarde die per sprint geleverd werd in eerste instantie omlaag omdat relaitef meer dan voorheen tijd in sprint gespendeerd werd aan het oplossen van bugs in plaats van aan nieuwe functionaliteit.

Binnen de kortste keren werden diverse extra tests ingericht en geautomatiseerd. Hierdoor ging de kwaliteit van een release omhoog omdat voor het eind van de sprint bugs al werden gevonden én opgelost. 

Het "eat your own dog food" principe werkte feilloos. Dit betekent uiteraard niet dat er nooit meer bugs zijn of dat dit effect bij ieder team zal ontstaan. Maar het toont wel aan wat de impact is van de verantwoordelijkheid van het oplossen beleggen bij het team wat initieel de logica ontwikkeld heeft. Die hebben daar ook de meeste kennis van, dus best logisch eigenlijk toch?

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 verbeteringen aan het softwareproduct 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!