17 januari 2016 werd er bij TestNet de Thema-avond over ‘DevOps & testautomatisering’ gehouden. De presentatie van Peter Nijenhuis gaat over DevOps en dan met name de vraag wat het is en wat er nodig is om goed te kunnen DevOpsen. DevOps, een interessant onderwerp waardoor ik besluit me op te geven voor deze avond, en waarbij ik mezelf de volgende vraag stel. Is het iets voor mij?

In een mooie mix van ervaringen, tips en trucs en discussies met het publiek krijgen we een beeld van wat het is en laat ik maar meteen met het einde beginnen. Ja, het is ook iets voor mij, als tester.

Eens kijken wat ik van de kennis mee kan nemen in mijn dagelijkse werk en de verbetertrajecten, die we aan het doorlopen zijn.

Agile versus DevOps
Één van de grootste verschillen tussen wat ik nu in mijn werk als Agile tester ervaar en DevOps, zie ik langskomen in een quote van Werner Vogels (CTO van Amazon), “You build it, you run it!”. Op mijn huidige opdracht is het eigenlijk uit onze handen zodra het naar productie gaat. Ondanks dat ik werk in een Agile omgeving, is er nog een figuurlijke muur tussen Dev en Ops. Verder ervaar ik de pijn van bevindingen in productie niet echt, hooguit als er ‘user stories’ op de backlog terecht komen of in de sprint getrokken worden, ten koste van wat anders.

Het volgende verschil dat langskomt is de snelheid. Werken wij nog in sprints van 2 weken en kijken we lachend naar de bedrijven, die misschien eens per half jaar een release hebben, zo worden wij juist bekeken door DevOps. Twee weken, dat is een eeuwigheid! Sowieso heb je het bij DevOps niet meer over een start en een einde van een sprint, het gaat continu door. Desnoods met 100+ opleveringen per dag.

Meer mogelijkheden DevOps voor mijn huidige werkomgeving
Ik zie in DevOps een aantal mogelijkheden, zeker omdat ik een persoon ben die continu wil verbeteren. De problemen waar wij in ons werk tegenaan lopen, komen zo te horen niet voor in de ideale wereld van DevOps. Wat nou als wij ook een soort pilot zouden starten om richting DevOps te gaan? Wat de uitkomst ook zou zijn, we zouden er sowieso profijt van hebben. Bijvoorbeeld op het gebied van de handmatige regressietest. Elke twee weken moet deze weer opgepakt worden en is daar een groot deel van het personeel mee bezig, om zeker te weten dat we met vertrouwen naar productie kunnen. Bij DevOps heb je dit niet meer, dat is ook niet echt mogelijk als je meerdere keren per dag naar productie gaat. Maar hoe krijg je het voor elkaar om zoveel vertrouwen te hebben dat je meerdere keren naar productie kan?

Ik besluit dit als verbeterpunt mee te nemen.

Daarnaast hang ik maar weer eens een spreuk aan de muur:

“Continuous improvement is better than delayed perfection”.

Stop even met lezen en ga nog even terug naar die spreuk, lees hem nog een keer en laat hem even goed op je inwerken.

Ik denk dat hier de kern ligt, maar niet alleen voor mijn verhaal maar voor zoveel zaken in je werk. Hoe vaak heb je geen dingen die je maar niet oppakt, omdat je weet dat wat je gaat doen nog niet perfect is? Stop met denken. Doe wat!

Doe iets, monitor wat er gebeurt, maak desnoods fouten (tenzij er hierdoor gewonden zullen vallen, dan niet natuurlijk), test het, verbeter het, organiseer brainstormsessies, vertel wat je doet, deel je successen, maar geef ook bijvoorbeeld aan waar je hulp nodig hebt.

Wat je zoals moet doen om van Agile naar DevOps te gaan
Dit is natuurlijk, en niet erg, maar het houdt wel in dat je commitment moet hebben, en dat er een gemeenschappelijk ‘sense of urgency’ nodig is, om iedereen achter je te hebben staan om te kunnen verbeteren. Daarnaast zal je afspraken moeten maken hoe je één en ander gaat aanpakken. Bijvoorbeeld door een tweede backlog te maken en daar de DevOps-zaken op te zetten en die dan ook op te pakken, bijvoorbeeld voor 25% van de tijd? Zorg er vooral voor dat dit getrokken wordt door iemand, die er op gebrand is om die verbeteringen door te voeren, iemand die stevig in zijn schoenen staat, die kan enthousiasmeren, iemand die het leuk vindt om bij wijze van spreken op een fruitkistje te gaan staan (of misschien wel letterlijk?!) en zijn verhaal te doen. Zorg voor een veilige plek waarin dit alles geprobeerd kan worden, zorg dat dit vertrouwen ook uitgesproken wordt, zorg voor een cultuur waarin niet op de vingers getikt wordt bij het maken van fouten. Bij dit alles moet rekening gehouden worden dat vertrouwen ‘komt te voet en gaat te paard’.

En natuurlijk zullen er mensen zijn die niet willen veranderen. Het is immers niet onnatuurlijk om te denken ‘het gaat toch goed zo, never change a winning team, laat het lekker zo!’. Ga met deze personen in gesprek.  Vraag hem gewoon waar hij bang voor is, wat is zijn angst om te veranderen?

Begin klein. Met een klein team, ontdek de beren op de weg, en los het op. En dan snel door naar de volgende stap. Het is allemaal ervaring die gebruikt kan worden bij de andere teams die gaan volgen. En die tijdelijke dip in de velocity, die zal snel weer stijgen door de verbeteringen die worden doorgevoerd!

Het was een mooie avond, ik heb weer ideeën opgedaan die ik in mijn dagelijkse werk door ga voeren. Tijdens de avond kreeg ik een tip voor een boek, dat ik meteen maar besteld heb: “De vijf frustraties van teamwork door Patrick Lencioni”. Maar daarover later wellicht meer.

(Dit verhaal is op 17 januari 2017 door Fred Steenbergen geschreven en verscheen eerder in het TestNet-nieuw. Op 5 juni 2018 is het geplaatst op Zeepkistje)