Het exitcriterium dat nog nooit een livegang heeft tegengehouden

Waar de twee elkaar raken

Een definition of done is een gedeelde afspraak wanneer een stuk werk als voltooid geldt. Zijn kracht is dat hij voor al het werk gelijk geldt en vooraf bekend is, zodat niemand per item opnieuw hoeft te onderhandelen over vakmanschap.

Het lesmateriaal zet hem niet tegenover het exitcriterium uit de testwereld. De twee overlappen sterk in bedoeling, maar niet altijd in scherpte. Een definition of done is vaak generiek geformuleerd voor alle werk ("code gereviewd, tests geslaagd, gedocumenteerd") en mist daardoor precies de risicogebaseerde verbijzondering die een bepaalde oplevering nodig heeft.

Het verschil zit dus in scherpte. Een generieke lijst stelt vast dát er is getest. Welke fout bij deze oplevering onacceptabel is en waaruit blijkt dat die fout er niet in zit, is juist wat een generieke formulering niet bevat.

Wat een criterium moet kunnen

Een exitcriterium moet inhoudelijk juist zijn, en het moet een oplevering daadwerkelijk kunnen tegenhouden. Twee zinnen uit dezelfde cursus zetten dat scherp:

Een exitcriterium dat nog nooit een livegang heeft tegengehouden, heeft waarschijnlijk nog nooit het juiste getoetst.

Een exitcriterium dat gehaald kan worden zonder de juiste dingen te hebben getest, is geen kwaliteitscriterium maar een resultaatgarantie voor zichzelf.

De eerste zin toetst de geschiedenis van een criterium. Je kunt hem toepassen zonder de formulering te lezen: vraag na hoe vaak dit criterium een oplevering heeft opgehouden en wat er die keer aan de hand was. Een criterium dat niemand ooit heeft zien leiden tot "nee, nog niet klaar" is verdacht, en de verklaring daarvoor ligt zelden bij een systeem dat toevallig altijd goed genoeg was.

Waar een definition of done generiek is geformuleerd, doorstaat hij die toets moeilijk. Hij is geschreven om voor elk item te gelden, en daardoor formuleert hij weinig waar een concrete oplevering op kan stranden.

Waar het risicodenken thuishoort

Hier ligt de valkuil, en het is een aantrekkelijke. Wie het bovenstaande leest, wil er iets naast leggen: een eigen exitcriterium per oplevering, opgesteld door degene die het risico draagt. Het lesmateriaal wijst dat af. De remedie is niet een tweede, concurrerend document, maar het risicogebaseerde denken in de bestaande definition of done te verwerken.

Praktisch betekent dat dat de generieke lijst blijft staan en er per oplevering een verbijzondering bij komt: welke risico's moeten gedekt zijn voordat dit ding gebruikers raakt, en waaraan zie je dat. Die verbijzondering hangt onder dezelfde afspraak en wordt in dezelfde beoordeling meegenomen.

Waarom die remedie beter zou zijn dan een tweede document, staat er niet bij. Wat hier volgt is dus een eigen redenering. Twee documenten naast elkaar kunnen een rangordevraag oproepen die pas wordt beantwoord wanneer het misgaat, en dan is de kans groot dat het document voorgaat van degene die haast heeft. Eén afspraak met een scherpere kop erop kent dat risico niet. Getoetst is die redenering niet.

De prikkel die eronder zit

Wie een criterium moet halen om live te mogen, haalt dat criterium. Dat gebeurt zonder kwade wil en meestal zonder dat iemand het zo noemt: testen worden zo gekozen dat ze slagen, en de risicovolle wijziging verhuist naar een volgende oplevering die het criterium niet raakt.

Dit is hetzelfde mechanisme als bij elk ander stuurcijfer: zodra een getal wordt gebruikt om af te rekenen wordt het onbetrouwbaar, en daarmee ook onbruikbaar om van te leren. Een exitcriterium draagt met opzet een besluit, en dat is het verschil met velocity; de uitweg dat het criterium eigenlijk niets voorstelde ligt hier niet open.

De vraag is daarom wie het criterium vaststelt en wie toetst dat het gehaald is. Zitten die twee bij dezelfde partij, dan levert ook een zorgvuldig opgeschreven criterium een resultaatgarantie voor zichzelf op.

Waar dit botst

Hier staat dit onderwerp tegenover een standpunt uit een andere cursus. Die stelt dat zware, traditionele goedkeuringsstappen negatief samenhangen met softwarekwaliteit, en het voorbeeld dat in diezelfde zin staat is de change approval board. Dezelfde cursus stelt dat controle die in het werk zelf is ingebouwd in gereguleerde sectoren grondiger uitpakt dan een periodieke toets achteraf. Een criterium dat een oplevering kan tegenhouden lijkt van buiten op zo'n goedkeuringsstap.

Van dichtbij valt dat beeld uit elkaar, want de kritiek heeft een smal doel. Een change approval board staat los van het werk: het oordeelt achteraf, op grond van bewijs dat voor die toets is verzameld en door anderen wordt gecontroleerd. Een exitcriterium kan een oplevering net zo goed tegenhouden, maar het is vooraf vastgelegd door de mensen die diezelfde oplevering bouwen en toetsen. De stap die dit artikel zet, is dat het bezwaar in die afstand tot het werk zit.

Dit artikel neemt daarom een positie in, en die gaat over de tolerantiegrens. Waar de poorten zitten en hoeveel het er zijn, volgt uit waar je die grens legt. Het mechanisme heet in de PM-cursus manage by exception: per laag in de organisatie worden marges afgesproken voor tijd, geld, scope, kwaliteit en risico, en zolang daarbinnen wordt gewerkt bemoeit de laag erboven zich er niet mee. Dreigt een marge te worden overschreden, dan gaat dat direct naar boven.

Binnen die grens beslissen de mensen die het werk hebben gedaan en de mensen die ermee moeten werken: de product owner, de tester, de ontwikkelaars en de senior gebruikers. Zij hebben de oplevering gezien en zij hebben het criterium vooraf afgesproken. Daarmee valt dat besluit buiten de kritiek uit deel 20, want het gremium en het werk vallen hier samen.

Valt een oplevering daarbuiten, dan gaat het besluit naar boven. Een livegang die de hele business raakt en die niet meer terug te draaien is, valt per definitie buiten de routinemarge, en daar hoort een besluit bij waar de stuurgroep en de senior gebruikers aan te pas komen. Een wijziging die binnen een iteratie wordt opgeleverd en die je kunt terugdraaien, blijft binnen de marge die het team zelf bewaakt.

Wat een poort waard is, hangt daarmee af van twee dingen: of de mensen erachter het werk hebben gezien, en of de grens die zij bewaken vooraf is afgesproken met degene die het risico draagt. Het aantal poorten komt in die weging niet voor. Ontbreekt een van die twee, dan levert de poort een handtekening op zonder oordeel erachter, en dat is het orgaan waar deel 20 tegen waarschuwt.

De andere kant op ligt een grens die dezelfde PM-cursus trekt. Een aanpassing die geen enkel beslismoment en geen enkele tolerantiegrens overlaat, gaat voorbij aan wat tailoring is: de mogelijkheid tot besturing is dan weggenomen, en die cursus noemt dat een principeschending.

Dit standpunt steunt op drie plaatsen in het materiaal: deel 20 van de SAFe-cursus voor de kritiek op zware goedkeuringsstappen en het voorbeeld dat daarin staat, paragraaf 4.2 en 4.3 van deel 9 van de testcursus voor de eis dat een criterium een livegang kan tegenhouden, en deel 2 van de PM-cursus voor manage by exception en voor de grens tussen tailoring en principeschending. Dat die drie hier naast elkaar staan is een keuze van deze kennisbank; in het materiaal zelf staan ze los van elkaar, elk in hun eigen cursus.