Vertrouwen in DevOps organisaties

Aard en cultuur

Als er één aspect is aan DevOps wat van belang is, is dat de aard en cultuur van de organisatie. Die aard en cultuur zien we ook terug in de aansturing van de organisatie. Natuurlijk zijn er generieke stuurparameters zoals budget. Maar, afhankelijk van doel en missie, zijn er daarnaast ook veel specifieke stuurparameters. Een transitie van traditionele IT naar een DevOps organisatie is een bijzondere uitdaging voor de gemiddelde organisatie, wat betreft sturing. En dat zit op meerdere facetten van de organisatie. 

IT-budget bij DevOps

Traditioneel is het IT-budget vaak gebaseerd op een meerjarige portfolio met IT-projecten. Wel, in een DevOps wereld bestaat dat niet. Dus moet er anders gekeken worden naar budget en  manieren om dat flexibel(er) te maken en dus op te sturen. Inmiddels zijn daar ervaringen mee die jou kunnen helpen voor jouw eigen organisatie de juiste (tussen?)vorm te vinden.

Sturen op vertrouwen

Aansturing vindt op meerdere manieren plaats. In DevOps organisaties in belangrijke mate door de architectuur. Die bepaalt op hoofdlijnen inhoudelijke keuzes en richting. Security heeft ook beleid en richtlijnen waarnaar gewerkt moet worden. En zo zijn er nog een aantal beleidsaspecten die richting en daarmee sturing geven.

Een facet wat wel erg veranderd is de HR-sturing. In DevOps is flexibiliteit een sleutelwoord voor de teams en de mensen. Natuurlijk binnen grenzen. Feit blijft dat de vastomlijnde en rigide functiehuizen geen bestaansrecht meer hebben en functies veranderen naar rollen die ook nog eens flink kunnen varieren in de tijd. 

En zo kunnen we een lijst opbouwen van zaken die behoorlijk wijzigen naar eigenlijk één samengevat begrip: sturen op vertrouwen. Vertrouwen in de mens, het team en datgene wat ze doen op dat moment (!) ook het juiste is. Natuurlijk blijven er dan nog genoeg aspecten over om op te sturen en te beoordelen. Zoals resultaat voor de klanten van de teams en de kwaliteit, in de breedste zin van het woord. Ook het functioneren in een team kan heel goed beoordeeld worden. 
Wat we dan zien gebeuren is eigenlijk waar management oorspronkelijk voor bedoelt was. Niet om te sturen en zaken op te leggen, maar om te faciliteren en ruimte en mogelijkheden te creëren zodat de beste resultaten bereikt worden. 

Zelfsturende DevOps teams

Helaas zien we vooral bij grotere organisaties, dat in de transformatie naar DevOps, aansturing erg moeilijk is. Management heeft snel de neiging om projectmatig te sturen, terwijl de teams zelfsturend willen zijn. Een gevolg kan zijn dat Product Owners in de knel komen doordat er van bovenaf allerlei verwachtingen worden opgelegd, bijvoorbeeld voor het afgeven van langetermijn planningen en de te kiezen oplossingen. We zien onder deze druk de focus van de Product Owner, en daarmee het team, komt te liggen bij vernieuwing en change. De Ops van DevOps komt daarmee ook onder druk te staan: een belangrijk argument om een Functioneel Beheerder c.q. Ops engineer in je team te hebben. Nog belanrijker is dat met de introductie van DevOps werken niet alleen de werkvloer veranderd. Het is een keuze die zeker ook voor het management gevolgen heeft. Geef de teams vertrouwen en stuur op hoofdlijnen. 

Controleren

Uiteraard is controle ook belangrijk. Controle in een DevOps organisatie is een heel ander spel dan in traditionele IT. Het is vooral gericht op kwaliteit van werk zoals “code quality”, gevoed met informatie vanuit het Ops “domein”, resultaat voor de klant op basis van informatie vanuit de Product Owners en budgetuitnutting, actuals versus plannend maar dan opgebroken naar de value chain of business domeinen. Hoe de opdeling van de totale business architectuur ook is. En natuurlijk in sprints of planning increments (per kwartaal). Wij zijn alvast benieuwd naar de resultaten van deze controles.