Q
terug

Driehoek people-process-technology helpt DevOps verder

DevOps staat momenteel volop in de belangstelling. Veel organisaties experimenteren ermee en zien er de voordelen van in. Ook komen ze erachter dat niet alle DevOps-teams even goed presteren. Samenhang tussen de teams is ook geen vanzelfsprekendheid. Tijd om te kijken naar manieren waarop DevOps op een hoger plan te krijgen is. Wie DevOps-teams productiever wil maken of ervoor wil zorgen dat ze minder fouten maken, kijkt naar drie aspecten, de bekende People-Process-Technology. Door Mark Elbertsen, managing director bij Quint Technology.

Drie aspecten

Het menselijke aspect, met name teamwork, is zeer belangrijk, niet alleen in DevOps maar ook in agile softwareontwikkeling. Het wil zeggen dat de medewerkers in de teams vertrouwen hebben in de nieuwe werkwijze en zien dat het management erin gelooft en ‘ervoor gaat’. Als team meer vrijheid en autonomie krijgen, is ook een belangrijk criterium. Automatiseren is het motto als het over het procesaspect gaat. Er is dan een goede workflow van idee naar inproductiename, een goed gedefinieerd proces dat door middel van automatisering leidt tot een geoliede machine. Is zo’n generiek proces er niet – zeker voor deployments en releases heel belangrijk – dan gaan teams improviseren en shadow IT in gebruik nemen.

Daarmee komen we bij de derde factor, de technologie. Zonder tech geen DevOps, in mijn beleving. Met de inzet ervan kan het in de praktijk fout gaan wanneer diverse tools niet goed geïntegreerd zijn. Wanneer teams niet goed functioneren of samenwerken, zie je al snel het aantal herstelacties toenemen ten koste van het opleveren van nieuwe functionaliteit. Er zijn tal van nuttige metrics in DevOps die helpen een goed beeld te krijgen. De velocity (productiviteit) zal naar beneden gaan, de ‘first time right’-ratio kan dat ook doen.

Regie versus autonomie

Een goede regie op DevOps is heel belangrijk. Een groot aantal autonome teams zonder regie is als een vloot met schepen zonder admiraal, hoorde ik eens een IT-manager zeggen. Een heel goed beeld, maar er lijkt een discrepantie te zijn tussen het ideaal van autonome teams en de behoefte aan regie op strategisch niveau. Die discrepantie is maar schijn, want we hebben het over verschillende niveaus.

SAFe, het Scaled Agile Framework, is een raamwerk dat is ontwikkeld om agile werken in de organisatie op te kunnen schalen en dat ook voor DevOps veel bruikbare elementen bevat. Zo maakt SAFe onderscheid tussen de portfolio-, programma- en teamniveaus. Regie wordt op portfolioniveau gevoerd door door een CIO of CxO dan wel de directie. Daar wordt bepaald waar de organisatie haar focus heeft en welke services belangrijk zijn om de schoorsteen rokend te houden. Op teamniveau ligt de regie bij de teams. Dat geeft ze een gevoel van eigenaarschap van de dienst die ze leveren.

Je zou kunnen zeggen dat de visie en strategie van het portfolioniveau komen en worden aangevuld met de ideeën die bij de teams leven. Dat vraagt wel wat van de verantwoordelijke op portfolioniveau, die in staat moet zijn de dialoog met de teams te voeren. Het gaat dan niet zozeer over de DevOps-straat (‘van idee, via ontwikkeling, testen en deployment naar release’), maar over de vraag wat de visie is op de dienst die de organisatie levert. Aan de hand daarvan zijn goede teams heel goed in staat te bepalen hoe ze die diensten gaan leveren.

Tooling en integratie

Tooling, en het gebrek aan integratie daarvan, is een probleem dat al is aangestipt. Hoe verbind je alle tooling als integratie niet op peil is in een organisatie? Waar begin je, welke stappen zet je? Om te beginnen: als het gaat om integratie, heb je het niet alleen over tooling. Bepaalde processen wil je standaard maken voor meerdere teams. Doe je dat niet, dan is het hecht integreren van tools zinloos.

Stel de teams dus in staat met elkaar samen te werken. Ze zijn autonoom, maar dat betekent niet dat er geen standaardprocessen voor alle teams hoeven te zijn. Die dienen er wel degelijk te zijn, bijvoorbeeld voor het releaseproces – hoe je iets naar productie brengt. Daar wil je wel standaardisatie in hebben, om te voorkomen dat de organisatie op allerlei verschillende manieren nieuwe diensten aangeboden krijgt. Daarnaast – daar heb je de schijnbare discrepantie weer – wil je dat de teams de vrijheid houden om te werken zoals ze willen. En dan zijn we terug bij de tooling. Het is helemaal niet erg wanneer het ene team met Jira werkt, het andere met Excel en het derde met ServiceNow. Het is wel erg wanneer daarbovenop een tool ontbreekt die de regiefunctie heeft. Een voorbeeld daarvan is XL Release van XebiaLabs, dat alle stappen in de workflow van het releaseproces automatiseert, over de teams heen. Diversiteit in tooling binnen de teams is geen probleem, mits je de verbinding zoekt en toewerkt naar een centraal platform. Dat heb je nodig om regie te kunnen voeren.

Wat XL Release is voor het releaseproces, is ServiceNow voor de overkoepelende regie. ServiceNow automatiseert alle typen services, van customer services tot IT- en HR-services. Hier komt alle data bij elkaar, aan de hand waarvan goede besluiten over prioritering zijn te nemen. Het is dan heel mooi wanneer de informatie daarover weer bij de teams terechtkomt.

De tools die we hier noemen, maar ook veel andere, zijn tegenwoordig heel goed in staat data uit allerlei bronnen (dus ook de eigen tools van de teams) op te nemen. Integraties zijn steeds makkelijker te maken. Je hoeft teams niet te dwingen een bepaald platform te gebruiken om regie te kunnen voeren. Belangrijk is wel kaders te stellen waarbinnen teams vrij kunnen handelen en hun keuzes op het gebied van tooling kunnen maken.

Van losse taken naar proces

Om van allerlei losse taken een inzichtelijk proces te maken, heb je in de eerste plaats een team met competente mensen nodig. Daarnaast is er een pijplijn die de hele leveringsketen, van A tot Z, bestrijkt. Is die keten van processen eenmaal goed gedefinieerd, dan zal de volgende ambitie zijn om steeds meer te gaan automatiseren. Daarmee krijg je het proces nog sneller en ook vaak beter. Dat is de uitdaging, om bijvoorbeeld de time-to-market van de organisatie te gaan versnellen.

In dit opzicht is de theorie verder dan de praktijk. Een select gezelschap van bedrijven heeft deze aanpak al geïmplementeerd. Er zijn dus al wel enkele goede voorbeelden, waardoor organisaties zich kunnen laten inspireren: hoe stel je de pijplijn op, welke tooling zet je in, hoe laat je de tooling goed functioneren?

Teamcultuur

We begonnen bij het menselijke aspect en eindigen ermee. Hoe werk je aan een teamcultuur waarin de leden leren van fouten, waarin samenwerking, vertrouwen en kennisuitwisseling centraal staan? Hier is een top-downbenadering, vanuit het management, belangrijk. Er zullen altijd wel een paar teams zijn die als early adopters hun zaakjes in dit opzicht goed voor elkaar hebben, maar voor de hele organisatie is het zaak top-down stappen te zetten. Het draait om commitment, vastberadenheid: “Dit is hoe we het gaan doen en waar we naartoe willen. En daar is DevOps onderdeel van.”

Ook op andere manieren kan het management laten zien dat het menens is en DevOps serieus wordt genomen. Dat geeft de teams vertrouwen. We hebben het dan over schijnbaar ‘operationele’ zaken, zoals een werkplek met alle faciliteiten, geschikt voor deze manier van werken. Chillrooms, een keer gamen, een grote vloer waar tien teams naast elkaar kunnen werken, met elk een set bureaus, stand-upboards, napraatruimtes en ga zo maar door. Het werkt allemaal mee om de teamleden te laten zien dat het management de daad bij het woord voegt. En dat geeft ze het vertrouwen om fouten te durven maken en daarvan te leren, om goed samen te werken en daadwerkelijk kennis uit te gaan wisselen.

DevOps komt tot zijn recht

Wie de prestaties van DevOps-teams wil verbeteren, kan niet om de mantra people, process and technology heen. Het heeft weinig zin om de modernste tools in te zetten als er geen centraal platform is. Net zo min als het zin heeft om tools te integreren als de processen niet op orde zijn. Betere prestaties blijven uit als er geen standaardisatie is en een te automatiseren pijplijn ontbreekt. We begonnen en eindigden niet voor niets met de menselijke kant van DevOps. Als het management commitment toont en de juiste omstandigheden creëert, krijgen de competente mensen in de teams vertrouwen en gebruiken ze de vrijheid om hun kunnen te laten zien. Dan komt DevOps pas goed tot zijn recht.