Kwaliteit vereist dienend leiderschap
Laatst kwam een manager naar mij toe en vroeg ‘Waarom zorgen die ontwikkelaars niet gewoon dat de codekwaliteit beter wordt en de security issues opgelost worden? We hebben dit toch afgesproken?’ Ik keek hem aan en vroeg: ‘Heb je wel eens aan de ontwikkelaars gevraagd wat ze daarvoor nodig hebben?’ Ik werd vreemd aangekeken en kreeg als reactie: ‘Zo moeilijk is dat toch niet, laten we een quality gate in de pipelines bouwen!’
Het heeft mij aan het denken gezet. Deze manager refereert aan een afspraak die helemaal geen afspraak is. Het was een eenzijdig statement vanuit het management. Vanaf datum x voldoet alle software aan norm y! Dit werd opgelegd en dwingend.
Kwaliteit in welke vorm dan ook vereist in mijn ogen leiderschap. Sterker nog, het vereist dienend leiderschap. In dit blog wil ik nader stilstaan bij de verschillende soorten dienend leiderschap die nodig zijn om kwalitatief goede software te realiseren. Maar laten we er eerst bij stilstaan wat kwaliteit is.
'Kwaliteit', het meest wollige begrip in softwareontwikkeling
Als voormalig tester heb ik menig discussie gevoerd over wat kwaliteit nu is. De meeste testers zullen beamen dat “Quality is value to some person (who matters)” de bekendste quote is. Deze quote is van Jerry Weinberg, en aangescherpt door James Bach & Michael Bolton. De klant/gebruiker (who matters) is de enige die kan aangeven of iets aan de verwachtingen voldoet en daarmee een kwaliteitsoordeel kan geven. Wordt zijn/haar probleem opgelost en is het bedrijf winstgevender, dan heeft de applicatie waarde. Waarde en kwaliteit zijn voor mij uitwisselbare begrippen.
Toch vind ik dat er een gap zit in het statement van Jerry Weinberg en dat is dat het woord duurzaam mist. In Jerry zijn statement kun je stellen dat een slecht ontwikkelde applicatie die niet te onderhouden is toch van hoge kwaliteit kan zijn, omdat deze het probleem van de klant oplost. Zijn statement houdt geen rekening met de interne applicatiekwaliteit. Slechte codekwaliteit is prima binnen de lean start-up gedachte om zodoende te experimenteren en snel te leren.
Binnen grote organisaties die zeer bewust om dienen te gaan met risico’s zoals financiële of risico’s waarbij mensenlevens gepaard gaan kan men niet zomaar experimentele applicaties deployen. Bugs en slechte codekwaliteit zorgen dat het ontwikkelteam minder adequaat wijzigingen kan doorvoeren. Security gaten, outdated open-source libraries kunnen risico’s opleveren in productie. Het is belangrijk om snel en veilig geplande (functionele wijzigingen) en ongeplande wijzigingen (bug-fixes, security updates) door te kunnen voeren.
Als organisatie moet je oog hebben voor de interne kwaliteitsaspecten en deze zijn vaak onderbelicht in organisaties. Dit komt omdat veel IT-organisaties zogenaamde feature fabrieken zijn. Code kwaliteit krijgt geen prioriteit.
Feature fabrieken
Binnen organisaties levert de IT diensten aan de business. De business heeft een probleem, verzint vaak zelf de oplossing en IT implementeert dit. Dit is een continue proces en wordt keer op keer herhaald. Incentives zijn gebaseerd op hoeveel features/user story’s of nog erger hoeveel punten er gerealiseerd worden.
Het management wil in een feature fabriek graag meer software zien en stuurt op output. Kwaliteit is zelden een output parameter omdat dit zo lastig te definiëren is in metrieken. Zodra kwaliteits-output metrieken worden zal er automatisch valsgespeeld worden.
Als voorbeeld wil ik hier de 80% unit code dekking aanhalen. De context ontbreekt bij zo’n stelling, waarom 80%? Waarom niet 75% of 90%? Ik kan makkelijk 100% unit test code dekking halen zonder iets te testen want ik kan alle daadwerkelijke checks achterwegen laten. Dit gebeurt dus ook. Niks geeft aan dat het goede testen zijn.
Management kijkt binnen een feature fabriek zelden naar de outcome. Met outcome hebben we het over hoe het ontwikkelteam direct impact maakt op de bedrijfsdoelstellingen. Draagt de ontwikkeling bij aan de directe bedrijfsdoelstellingen zoals winst generen, kosten besparen, toezichthouders tevredenstellen. Als het ontwikkelteam hier zelfstandig de oplossing kan verzinnen ontstaat er automatisch een grote buy-in van het ontwikkelteam. dat 2/3 van alle features die de IT realiseert geen of zelfs een negatieve waarde heeft.
Softwareontwikkeling moet gestuurd worden op basis van impact en zodra dit gestuurd wordt op impact zal de kwaliteit omhooggaan. Het ontwikkelteam wordt immers verantwoordelijk gehouden voor de oplossing en is ook probleem eigenaar als er slechte kwaliteit wordt geleverd.
Dienend leiderschap
Als je als organisatie kwalitatief goede software wil maken, dan dien je als organisatie kwaliteit te ademen. Kwaliteit is namelijk niet het resultaat en/of de verantwoordelijkheid van een ontwikkelaar, maar van de gehele organisatie. Alle betrokken rollen dienen zich bewust te zijn dat er dienend leiderschap moet zijn om kwaliteit te leveren. Daarnaast is ook empathie nodig om in te zien dat geen enkele situatie en context hetzelfde is.
CTO en managers
De CTO en managers zullen leiderschap moeten tonen door de organisatie te transformeren van feature fabrieken naar waardenstromen. Managers moeten doorgronden dat ons IT- landschap niet een moeilijk geheel is, maar een complex geheel.
Met een complex systeem ontstaan er nieuwe uitdagingen in o.a. de balans zoeken tussen stabiliteit en innovatie. Bekijk voor meer informatie over dit ontwerp onze whitepaper De juiste balans tussen innovatie en stabiliteit.
Transformeer de IT op een dusdanige wijze dat deze veerkrachtig om kan gaan met verstoringen in plaats van het proberen te voorkomen van verstoringen omdat verstoringen gegarandeerd voorkomen. Onder veerkrachtigheid verstaan we bijvoorbeeld het limiteren van schade (limit blast radius) door bijvoorbeeld het inzetten van message queing en de migratie naar de cloud waarbij de infrastructure as code wordt uitgerold
Elke organisatie is uniek. De managers zullen een organisatie moeten creëren waarbij het veilig is om te leren en veilig is om fouten te maken. Want zonder fouten maken leren wij mensen slecht. Hoe leren wij? Hoe leer ik? Hoe leer jij? Worden de meest belangrijke vragen om tot een organisatie te komen die losbreekt van feature fabrieken en waarde gedreven werkt.
Kwaliteit meten doen we niet door SonarQube analyses in dashboarding te zetten en de teams te confronteren met eventuele slechte scores. Er moet gekeken worden naar wat een team bereikt, dus de outcome en hoe een team bijdraagt aan de bedrijfsdoelstellingen.
Architecten
Architecten moeten een leidende rol spelen om applicaties voor te bereiden voor kwaliteitsaspecten rondom moderne applicatie-architectuur, testbaarheid, deploybaarheid en security by design. De architect dient feedbackloops te creëren tussen de ontwikkelteams en de kaders die de architecten met elkaar bepalen binnen de organisatie. Deze feedbackloops zijn essentieel om buy-in te krijgen van de ontwikkelteams. Deze feedbackloops dragen bij aan het vergroten van de kennis en het leren.
Architecten moeten zich bewust zijn van het agile principe: “The best architectures, requirements, and designs emerge from self-organizing teams.” en dienen daarbij altijd bereikbaar te zijn voor ontwikkelteams ten behoeve van ondersteuning.
Product Owner
De product owner dient het ontwikkelteam in zijn kracht te zetten door samen met de stakeholders het probleem goed te schetsen en de oplossing bij het ontwikkelteam te laten. Deze persoon moet open staan voor kritische vragen vanuit het ontwikkelteam en niet zelf met oplossingen komen.
Dienend leiderschap ontstaat door initieel samen met het ontwikkelteam de vraag (het probleem) dusdanig te bevragen zodat er een goed beeld ontstaat van wat het probleem überhaupt is. De product owner moet daarnaast het team helpen om een ander belangrijk agile principe te hanteren namelijk: “Simplicity--the art of maximizing the amount-of work not done--is essential.”.
Engineering Lead
De engineering lead moet oog hebben op het vakschap. Deze persoon moet de duwende kracht zijn achter de techniek. De engineering lead moet coachende vaardigheden hebben om zo ontwikkelaars en testers in teams betere ontwikkelaars en testers te maken. Een artikel van Dan North over ‘The worst programmer I know’ is een fantastisch voorbeeld van een dienend leider die zelf niets uitvoert en zijn team ten volste ondersteunt.
De engineering lead zal daarnaast oog moeten hebben voor bottlenecks in het proces en deze samen met een scrum master op moeten pakken.
Ontwikkelaar
Ontwikkelaars kunnen leiderschap tonen door te doen aan pair programming, zeker als er een combinatie ontstaat tussen ervaren en minder ervaren ontwikkelaars. Zodoende kan men leren van elkaars ontwikkelvaardigheden. Daarnaast is een belangrijk aspect van leiderschap tonen, het boy-scouting principe: “Always leave the code you are working on a little bit better than you found it.” Approval testing kan helpen met het refactoren van code.
Gebruik tools als SonarQube, Dependency scanning, linters, pipelines en een geautomatiseerd vangnet in de vorm van snelle unit testen om zekerheid te krijgen. Deze tools zijn er voor ontwikkelaars als hulpmiddelen.
Tester
De tester kan leiderschap tonen binnen een DevOps omgeving door te kijken of er op een andere manier kwaliteit kan worden gerealiseerd. De modern testing principles van Alan Page en Brent Jensen gaan hier juist over hoe je als team kwaliteit kan leveren. Een tester binnen DevOps moet het team meehelpen en coachen voor risk appetite. Hoe kunnen we risico’s verkleinen en wegnemen als team? Hoe kunnen wij leren van de features die wij gebouwd hebben en hoe meten we dit?
Daarnaast zijn de meeste testers uitermate geschikt om samen met een scrum master en de engineering lead bottlenecks in het proces weg te werken. Ze zijn immers kritisch. Ondersteun daarnaast ontwikkelaars met approval testing als er gerefactored moet worden.
Joost Voskuil, DevOps Consultant
