De Definition of Done is een essentieel onderdeel van scrum. Ieder zichzelf respecterend scrum team heeft er een, maar er zijn maar weinig scrum teams die de Definition of Done ook echt serieus nemen. Meestal is het een wassen neus, een document voor de bühne of in het beste geval een checklist waar je best van mag afwijken als je maar een beetje een plausibele uitleg hebt.

Een limiet is er om je er aan te houden

In de Definition of Done staan de kwaliteitscriteria waar ieder opgeleverd product aan moet voldoen. Het is voor het scrum team de meetlat die bepaalt of je iets af hebt of nog niet. Deze meetlat is zo strikt dat als je er niet aan voldoet, je het betreffende item niet mag opleveren. Formeel mag je het resultaat niet eens laten zien tijdens de sprint review meeting. Dat vinden de meeste teams wel heel erg spannend en daarom wordt de Definition of Done lekker vaag gehouden, zodat je er in de meeste gevallen wel mee weg komt als de kwaliteit even wat minder is.

Wat telt is het resultaat, niet jouw inzet

Een paar maanden geleden schreef ik een blog waarin ik ervoor pleitte om procesafspraken uit de Definition of Done te halen. Van die lekker vage afspraken, dat er een peer review moet plaats vinden of dat alle testen moeten zijn uitgevoerd. Het zijn afspraken waar je alle kanten mee op kan en die je met een beetje verhaal altijd kunt afvinken. Ze zeggen echter niets concreets over de geleverde kwaliteit en daardoor geven ze ook geen enkel aanknopingspunt om te verbeteren. Dat komt omdat ze gaan over inzet en niet over resultaat, maar ook omdat ze vaak niet SMART(Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden) zijn geformuleerd.

De Olympische limiet ligt wel heel erg hoog

Als je de stap gemaakt hebt om procesafspraken uit je Definition of Done te schrappen en het is gelukt om de vaagheid eruit te krijgen, dan is er nog het gevaar van de Olympische lat. President Xi van China heeft in Peking de Olympische winterspelen geopend en de komende weken kan de hele wereld weer genieten van sporters die het beste willen laten zien van wat ze in huis hebben. Het motto van de olympische spelen is citius altius fortius en dit sneller, hoger, sterker moet de deelnemers motiveren om iedere keer weer een beetje beter te presteren. Het gaat in de topsport echter al lang niet meer om alleen maar het meedoen. Er moeten medailles gewonnen worden en het liefst een paar meer dan 4 jaar geleden. Als je mee wilt doen dan zul je moeten voldoen aan de Olympische limiet. Haal je die niet, dan doe je niet mee.

Voor veel teams wordt een kwaliteitslimiet in de Definition of Done opgesteld die op het allerhoogste Olympische niveau ligt. Een limiet waar normale stervelingen onmogelijk aan kunnen voldoen. Het is meer een Definition of Perfect. Er zijn naast de afnemers van het product namelijk nog veel meer partijen die belang hebben bij een hoge kwaliteit. Ze stellen eisen aan beveiliging, bruikbaarheid, beschikbaarheid of andere niet-functionele kenmerken. De lat wordt vaak nog een beetje hoger gelegd vanwege imago en reputatie. Eisen die vaak worden gesteld door management, ondersteunende afdelingen of de maatschappij. Denk bij het laatste bijvoorbeeld aan wet- en regelgeving. Alle eisen worden vaak met de beste bedoelingen opgesteld en aan de Definition of Done toegevoegd. En zo wordt de stapel eisen waar een team aan moet voldoen steeds maar hoger en hoger. En uiteindelijk ligt de limiet zo hoog dat alleen de allerbesten er nog aan kunnen voldoen. En dan nog alleen als de omstandigheden perfect zijn en de druk niet al te hoog is.

Nog veel belangrijker dan kwaliteit is vaak de druk op de hoeveelheid die opgeleverd moet worden. Veel organisaties verwachten van hun teams dat ze steeds een beetje beter worden en dat zich dat vertaalt in nog meer opgeleverde functionaliteit. Natuurlijk is er niets mis met beter worden waardoor je met dezelfde inspanning meer waarde kunt leveren. In de praktijk is de druk om meer te leveren echter vaak groter dan wat de teams aan kunnen en wordt de prijs betaald door consessies te doen aan de kwaliteit of, erger nog, wordt roofbouw gepleegd op de medewerkers. Teams vinden allerlei manieren om niet aan deze enorme berg eisen te hoeven voldoen. Dat gaat van negeren, de schuld afschuiven en wegredeneren tot aan verdoezelen, creatief omgaan met de regels en manipuleren aan toe. De hele trukendoos wordt open getrokken.

Iedereen wil meebeslissen

De oorzaak dat er teveel aan wishful thinking wordt gedaan, is niet de enige reden dat de Definition of Done niet de plek krijgt die hij verdient. Een andere belangrijke oorzaak is dat de eisen voor de Definition of Done van buitenaf worden opgelegd. Belanghebbenden leveren hun lijstjes in bij het team met de mededeling dat dit de eisen zijn waar ze aan moeten voldoen. Vervolgens verwachten ze dat het team wel even regelt dat ze er aan zullen voldoen. Ze houden er geen rekening mee dat iedere toevoeging of wijziging aan de Definition of Done impact heeft voor het team. Het levert extra werk op in de vorm van controles, rework of extra functionaliteit. Teams zouden dit niet zomaar mogen accepteren. Het extern opleggen van allerlei dwingende eisen aan het team is een aantasting van hun autonomie met als gevolg dat het team zich geen eigenaar voelt. Het is dan ook volstrekt logisch dat ze zichzelf daartegen beschermen door de rol van de Definition of Done te minimaliseren.

Handige tips voor een praktisch toepasbare Definition of Done

Om een goede start te maken zouden teams eerst moeten inventariseren wat het concrete huidige kwaliteitsniveau is. Leg dit niveau vast in de Definition of Done. Als meerdere teams aan hetzelfde product werken dan geldt het niveau van het minst presterende team. Dat is namelijk het niveau dat je als klant of belanghebbende minimaal mag verwachten en dat zal ongetwijfeld lager zijn dan wat de meesten ervan verwachten. Dit is een realistische start, want de teams hebben immers aangetoond dat ze dit kunnen halen. Van daaruit leggen de teams in gezamenlijk overleg de lat iedere keer een beetje hoger. De retrospective is de belangrijkste meeting die hiervoor wordt gebruikt, maar gebruik ook de sprint review meeting om de wensen en verwachtingen van belanghebbenden te achterhalen en met ze te bespreken. Iedere keer als je de lat een beetje hoger legt kun je bedenken wat de consequenties voor het team zijn, maar het is ook vooral een kwestie van gewoon doen. Ga iedere sprint een nieuw experimentje aan. Als het een keer niet lukt dan is dat niet erg. Je kunt immers altijd terugvallen op de vorige versie.

Zorg dat je de regie houdt en als je dit lang genoeg vol houdt kom je vanzelf weer op dat olympische niveau terecht, maar dan weet je ook zeker dat je het waar kunt maken.

Alles draait om efficiëntie

We schrijven 1911. Frederick Taylor publiceert zijn baanbrekende werk ‘The Principles of Scientific Management’ dat de komende honderd jaar het management denken zal beheersen. Stel je eens voor dat je in die tijd met hem in gesprek had kunnen gaan over een Agile transitie. Hoe zou dat gesprek er dan uit gezien hebben?

Taylor zou gezegd kunnen hebben dat een Agile transitie een complex proces is, maar dat je toch een aantal onderdelen kunt onderscheiden die altijd aandacht vragen. Het is een mindset en hij zal je dat aan de hand van zijn 4 principes toelichten. Zijn 4 principes zijn universeel en bedoeld om 3 dingen aan te tonen:

• het is cruciaal om verspilling te elimineren;
• de oplossing hiervoor ligt in systematisch management en niet in het vinden van de ideale medewerker;
• de basis hiervoor ligt in de wetenschap, gebaseerd op duidelijk gedefinieerde wetten, regels en principes.

Uitgangspunt is dat dit alles gericht is op het maximaliseren van voorspoed voor zowel de werknemer als de werkgever. Deze twee zijn niet tegengesteld aan elkaar, omdat voor beiden geldt dat maximale voorspoed in zijn ogen gelijk is aan maximale productiviteit. Dat was in zijn tijd een vernieuwend inzicht, omdat veel arbeiders en vakbonden de overtuiging hadden dat door het vergroten van efficiëntie banen op de tocht kwamen te staan. Werk dus vooral niet te hard, want dan zijn er minder mensen nodig en worden er collega’s ontslagen. Medewerkers hoeven volgens Taylor echter niet te vrezen voor hun baan als ze efficiënter worden, omdat daardoor producten goedkoper worden en dat leidt weer tot een groei van de vraag waardoor je juist meer mensen nodig hebt. Win win dus.

Hoe kun je zijn vier principes vertalen naar een Agile organisatie?

1. Analyseer werkprocessen

Bedenk voor iedere stap in het proces wat de beste methode is om deze uit te voeren. Bepaal wie de klant is en hoe zijn processen eruit zien. Een beproefde methode is het definiëren van waardestromen. Bepaal vervolgens wat de beste manier is om scrum teams hieraan te koppelen, zodat ze hun ​​taak zo efficient mogelijk kunnen uitvoeren. Je kunt nog met andere methoden zoals Kanban experimenteren om erachter te komen met welke methode het team het snelste is en de beste kwaliteit levert. Je kunt met één team starten en later andere teams toevoegen, zodat zij gebruik kunnen maken van de ervaringen en lessen van het eerste team.

Nog een tip van Frederick: standaardiseer onderdelen voor een efficiënte samenwerking, zoals programmeerstandaarden, het sprint ritme, architectuur uitgangspunten, de administratie in Jira etc, waarbij medewerkers zo goed mogelijk worden bijgeschoold om deze standaarden te kunnen opvolgen.

2. Het juiste team voor de juiste taak

Veel organisaties zijn te complex om alles door één team te laten doen. Definieer daarom onderdelen die ondersteunend zijn voor het team of die onafhankelijk van het team kunnen worden uitgevoerd en breng dit onder in aparte teams, zoals bijvoorbeeld de infrastructuur, financiën, opleidingen etc. Op deze manier reduceer je de complexiteit, houdt het team focus en kunnen ze zich op hun vakgebied specialiseren. Zorg daarom ook voor gerichte opleiding, training en coaching. Kan het werk niet door één team gedaan worden, creëer dan meerdere scrum teams die iedere voor hun eigen afgebakende stuk verantwoordelijk zijn. Deel het proces in kleine stukjes op, zodat ieder team focus kan houden. Door deze focus en omdat een team langere tijd bij elkaar blijft kan het een zeer efficiënt high performing team worden.

3. Gebruik de vaardigheden van medewerkers en vier successen

Streef er bij de teamindeling naar om de vaardigheden van werknemers te erkennen en ze werk te laten doen dat het beste bij hun ambities past, zodat ze zo productief mogelijk kunnen zijn. Vier successen met teams als ze resultaten consequent halen of overtreffen of als ze substantiële verbeteringen hebben doorgevoerd. Een extra beloning voor de beste teams is een mooie erkenning van hun prestaties. Evalueer de werkwijze, de gebruikte methodes en de resultaten op een wetenschappelijke manier en geef constructieve feedback voor verbeteringen.

4. Breng een professionele organisatiestructuur tot stand

Door ervoor te zorgen dat elk team begrijpt wat er van hen wordt verwacht kun je duidelijke afspraken maken over de benodigde communicatie. Als je bijvoorbeeld met epics en features werkt die door meerdere teams worden uitgevoerd, dan kun je de teams vragen bij te houden hoe het er voor staat met risico’s en voortgang, zodat de opdrachtgever (bijvoorbeeld een business owner) altijd op de hoogte is van de status. Product owners en managers kunnen terugkoppeling geven aan de strategische laag binnen het bedrijf om te kijken wat de voortgang is op de strategische doelen. De primaire rol van managers is tweeledig. Ze zorgen ervoor dat er duidelijk kaders en richtlijnen zijn en ze besteden aandacht aan de professionele ontwikkeling van werknemers. Ze monitoren de voortgang, geven terugkoppeling voor verbeteringen en ze zorgen dat men leert door te experimenteren.

Klinkt je dit allemaal best wel bekend in de oren en vind je het een logisch verhaal? Heb ik je in de war gebracht of voel je lichte irritatie of verbazing opkomen? Ik heet je in ieder geval van harte welkom in het 1911 van Frederick Winslow Taylor.

De Agile mindset

Ik ben voor deze mindfuck wel zo vrij geweest om hier en daar wat modern woordgebruik te kiezen. Natuurlijk kende men in die tijd de Agile, Scrum en Lean terminologie nog niet en ook de 4 principes formuleerde Taylor net even iets anders, maar ik heb de essentie niet veranderd. Die essentie, dat is de mindset waar we het altijd over hebben. Zo heb ik hiërarchie vervangen door structuur, talenten door ambities, rapporteren door terugkoppeling en individuen door teams, maar wordt het verhaal daardoor nou echt zo anders? Ik denk eerlijk gezegd dat hij het niet met me eens zou zijn om op team niveau te kijken, maar de andere wijzigingen zijn niet heel ingrijpend.

Wat maakt agile dan zo revolutionair anders? Het gedachtengoed van Taylor wordt volop bekritiseerd, maar moeten we ons er niet eens wat beter in verdiepen? In mijn volgende blog zal ik daar dieper op ingaan, maar ondertussen ben ik wel heel benieuwd naar jullie mening, inzichten en ideeën. Want wat is nou eigenlijk die agile mindset waar we allemaal zo vol van zijn en waarom is deze toch echt heel anders dan de mindset van Taylor?