Definition of Ready: voordelen en gevaren
Minder vaak gebruikt dan de Definition of Done, wordt de Definition of Ready door sommige teams ingezet om vast te stellen welke Product Backlog Items in een iteratie opgenomen mogen worden.
Je kunt de Definition of Ready zien als een grote, stevige uitsmijter die voor de deur van de volgende iteratie staat. Net zoals een uitsmijter alleen bepaalde mensen de club binnenlaat – de jonge, hippe en goed geklede – laat ook de Definition of Ready alleen bepaalde User Stories toe in de iteratie.
En net zoals een club zelf kan bepalen wie de uitsmijters wel en niet binnenlaten, kan elk team of elke organisatie zelf beslissen hoe hun Definition of Ready luidt. Er bestaat geen universeel geldige Definition of Ready voor alle teams.
Een patroon voor de Definition of Ready
Wat voor soort Stories zou onze uitsmijter dus in de iteratie kunnen toelaten? Hij zou bijvoorbeeld Stories kunnen binnenlaten die aan deze of vergelijkbare criteria voldoen:
De Conditions of Satisfaction voor de betreffende Story zijn volledig vastgesteld.
De Story is ingeschat en heeft een vastgestelde maximale grootte. Als het team bijvoorbeeld met Story Points werkt, stellen de teamleden een bepaald aantal Story Points vast en worden alleen Stories die aan dit aantal voldoen of kleiner zijn, in de iteratie opgenomen. Vaak ligt deze maximale grootte rond de helft van de Velocity van het team.
De User Interface Designer heeft al een mock-up of het volledige ontwerp gemaakt voor de schermen die met de Story te maken hebben.
Externe afhankelijkheden zijn weggenomen, ongeacht of het om teaminterne of -externe afhankelijkheden gaat.
Een Definition of Ready definieert de voorwaarden
Een Definition of Ready stelt het team in staat om criteria vast te stellen waaraan voldaan moet zijn voordat een story in een iteratie mag worden opgenomen. Het doel hiervan is om problemen te voorkomen nog voordat ze de kans krijgen om überhaupt op te treden.
Door bijvoorbeeld te zeggen dat alleen story's tot een bepaalde maximale grootte in een iteratie mogen worden opgenomen, voorkom je dat er aan een story begonnen wordt die te groot is om in één enkele iteratie af te ronden.
Zo kan het weigeren van story's met externe afhankelijkheden in de iteratie er ook voor zorgen dat deze afhankelijkheden de story of de hele iteratie niet in gevaar brengen wanneer het andere team zijn commitment niet nakomt.
Stel je bijvoorbeeld voor dat jouw team soms afhankelijk is van een ander team dat eerst een deel van het werk moet afronden. Jullie user stories kunnen dus alleen worden afgerond als het andere team zijn werk heeft gedaan – en dat op tijd, zodat jouw team ook nog de kans heeft om deze zaken te integreren.
Als dat team jouw team al regelmatig heeft laten zitten omdat ze niet op het beloofde moment klaar waren, dan zou het logisch zijn als jouw team besluit om geen story's meer in een iteratie op te nemen waarbij er nog een openstaande afhankelijkheid met het andere team bestaat.
Een Definition of Ready die stelt dat alle externe afhankelijkheden opgelost moeten zijn voordat een story in de iteratie kan worden opgenomen, zou voor zo'n team zinvol kunnen zijn.
Een Definition of Ready is niet altijd een goed idee
Sommige regels van onze uitsmijter zijn dus duidelijk een goed idee. Ik heb er bijvoorbeeld geen probleem mee als een team besluit dat er geen stories boven een bepaalde grootte in een iteratie getrokken mogen worden.
Toch kunnen sommige regels die ik vaker zie bij de Definition of Ready voor problemen zorgen – grote problemen. Laat me dat uitleggen.
De Definition of Ready is als de poort naar de iteratie. Er worden regels opgesteld en onze uitsmijter zorgt ervoor dat alleen stories worden binnengelaten die aan deze regels voldoen.
Als deze regels onder andere stellen dat iets voor 100 % afgerond moet zijn voordat een story in de iteratie opgenomen kan worden, wordt de Definition of Ready een behoorlijk grote stap richting een sequentiële Stage-Gate-aanpak. Dat houdt het team ervan af om agile te zijn.
Een Definition of Ready kan leiden tot Stages en Gates
Laat me dat even toelichten. Een Stage-Gate-aanpak wordt gekenmerkt door een reeks fasen (stages) in de ontwikkeling. Daarnaast worden bij de Stage-Gate-aanpak zogenaamde poorten (gates) oftewel checkpoints gedefinieerd. Werk kan alleen van de ene fase naar de volgende gaan als het door een poort komt.
Toen ik nog een klein kind was, gebruikte mijn moeder een Stage-Gate-aanpak voor het avondeten. Ik kreeg alleen een toetje als ik mijn bord had leeggegeten. Het avondeten en het toetje mocht ik niet tegelijkertijd eten.
Om het met een voorbeeld uit productontwikkeling te illustreren: stel je een proces voor met aparte design- en codeerfasen. Om van de design- naar de codeerfase te komen, moet het werk door een design-review-poort. De poort moet de volledigheid en grondigheid van het werk in de vorige fase waarborgen.
Als een Definition of Ready nu een regel bevat dat iets done moet zijn voordat iets anders gestart kan worden, brengt dit het team gevaarlijk dicht bij een Stage-Gate-proces. En dat zal het vermogen van het team om agile te zijn ondermijnen. Een Stage-Gate-aanpak is namelijk gewoon een ander woord voor een watervalprocces.
Agile teams zouden gelijktijdige ontwikkeling moeten oefenen
Zodra iets niet begonnen kan worden voordat iets anders is afgerond, kan het team niet meer gelijktijdig werken. Het gelijktijdig uitvoeren van werkzaamheden is echter een van de meest voor de hand liggende indicatoren dat een team agile werkt. Een agile team zou altijd een beetje analyse-, design-, test- en programmeerwerk tegelijkertijd moeten doen. Door gates in het ontwikkelproces in te bouwen, voorkom je echter precies dat.
Agile teams zouden simultane ontwikkeling moeten beoefenen, waarbij de verschillende activiteiten voor het opleveren van werkende software elkaar overlappen. Activiteiten zoals analyse, design, het schrijven van code en testen zullen nooit volledig gelijktijdig plaatsvinden – en dat is ook helemaal niet het doel. Het doel is dat deze activiteiten elkaar simpelweg zo veel mogelijk overlappen.
Doordat bij een stage-gate-aanpak bepaalde activiteiten voor 100 % af moeten zijn, wordt voorkomen dat andere activiteiten begonnen kunnen worden. En een Definition of Ready kan rechtstreeks tot zo'n stage-gate-aanpak leiden, als dergelijke regels in de Definition of Ready worden opgenomen.
Om deze reden raad ik de meeste teams aan om niet met een Definition of Ready te werken. Vaak is het onnodige overhead. En wat nog veel erger is: het kan een grote en gevaarlijke stap terug zijn naar een watervalprocces.
In sommige gevallen kan een Definition of Ready echter toegegeven problemen oplossen en het daarom waard zijn om te gebruiken.
De Definition of Ready goed gebruiken
Om de Definition of Ready succesvol te kunnen gebruiken, moet je regels vermijden die stellen dat iets voor 100% af moet zijn voordat een story in de iteratie mag worden opgenomen – misschien met uitzondering van afhankelijkheden van bepaalde teams of leveranciers. Daarnaast kun je beter kiezen voor richtlijnen in plaats van strikte regels in je Definition of Ready.
Hier is een voorbeeld van een regel die het team zou moeten herformuleren: „Bij elke story moeten er voor alle nieuwe schermen gedetailleerde mock-ups zijn."
Zo'n regel vormt een poort. Het voorkomt dat werkzaamheden gelijktijdig kunnen plaatsvinden. Een team met deze regel kan geen simultane ontwikkeling realiseren. Zolang niet voor elke afzonderlijke story een gedetailleerd design is uitgewerkt, is er ook geen werk aan de andere kant van de poort.
De betere variant zou zijn: „Als een story belangrijke nieuwe schermen bevat, moeten er vooraf al in voldoende mate mock-ups van de nieuwe schermen zijn gemaakt, zodat het team de resterende vragen en problemen gedurende de iteratie kan oplossen."
Kleine verandering, groot effect bij de Definition of Ready:
1. De regel wordt een richtlijn.
2. Door te zeggen dat de mock-ups alleen maar voldoende hoeven te zijn in plaats van af, staan we gelijktijdig werken toe.
Deze twee veranderingen brengen wat meer subjectiviteit in het gebruik van een Definition of Ready. We vertellen de portier nog steeds dat we graag jonge, hippe en goed geklede mensen in onze club willen hebben. Maar we geven hem meer vrijheid om zelf te beslissen wat "goed gekleed" eigenlijk betekent.
Deze tekst is afkomstig uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.
