De vorige blogs gingen over de pitfalls bij de Product Backlog, de Sprint Planning, de Daily Scrum, de Sprint en de Sprint Review. De laatste blog van deze serie gaat over de pitfalls bij de Sprint Retrospective. 

Pitfalls tijdens de Sprint Retrospective

Vorige week schreef ik over de feedbackloop voor het verbeteren van het product, de Sprint Review. Deze keer ga ik het hebben over pitfalls bij de feedbackloop voor het verbeteren van het Scrum Team, de Sprint Retrospective. Net als softwareontwikkeling is teamontwikkeling een voorbeeld uit het Complexe probleemdomein van het Cynefin Framework. (In de vorige blog heb ik meer uitleg gegeven over het Cynefin Framework.) De aanpak is dus ook hetzelfde: ‘Probe – Sense – Respond’. ‘Probe’ vindt plaats tijdens de Sprint, ‘Sense’ en ‘Respond’ tijdens de Sprint Review:  

“De Sprint Retrospective is een kans voor het Scrum Team om zichzelf te inspecteren en een plan te maken om zichzelf gedurende de komende Sprint te verbeteren.” 

Hoewel Scrum ouder is dan het Manifest voor Agile Software Ontwikkeling, kun je de Sprint Retrospective zien als een invulling van het 12e principe achter het Agile Manifest: 

“Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.” 

Dit is zeker niet uniek voor agility, PRINCE2 kent een principe “Learn from Experience”. Buiten Scrum is de waarde van verbetering van het team, dus ook erkend. What can possibly go wrong? 

1. Niet variëren in de gebruikte vorm

Er zijn letterlijk boeken en websites volgeschreven over verschillende vormen die je kunt gebruiken bij een Sprint Retrospective. Iedere vorm heeft zijn sterke (en zwakke) kanten en situaties waarin ze juist heel goed (of juist niet) in te zetten zijn. Experimenteer hier als Scrum Master mee. Het is natuurlijk helemaal niet erg om af en toe een Retrospective vorm opnieuw te gebruiken, maar als je iedere keer dezelfde vorm gebruikt kan het maar zo gebeuren dat je ook elke keer dezelfde verbeterpunten krijgt. Helemaal als je ook in de volgende pitfall trapt.

2. Verbeteritems uit retro’s laten verwaarlozen tijdens de Sprint, of niet uitvoeren omdat het ‘te druk’ is 

Sinds de update van november 2017 kan dit officieel gelukkig niet meer: de output van de Sprint Retrospective (de procesverbeteringen) komen niet meer op de Product Backlog maar er komt er minimaal één direct op de Sprint Backlog terecht. Hierdoor kan de Product Owner verbeteracties dus niet meer wegprioriteren. 
 
“De Sprint Backlog maakt al het werk zichtbaar dat het Ontwikkelteam heeft geïdentificeerd als noodzakelijk voor het behalen van het Sprint Doel. Om continue verbetering te garanderen, bevat het op zijn minst één procesverbetering met hoge prioriteit, die in de vorige Retrospective is geïdentificeerd.” 

 Dat een procesverbetering op de Sprint Backlog staat, wil helaas niet bij alle Ontwikkelteams zeggen dat ze ook uitgevoerd worden. Coach het Ontwikkelteam er in dat geval op procesverbeteringen te zien als elk ander soort werk, bijvoorbeeld door ernaar te vragen tijdens de Daily Scrum als ze het zelf niet benoemen. Zoals ik beschreef in pitfall 6 van de Sprint Planning, kan het uitvoeren van procesverbeteringen een wereld van verschil betekenen. Om die reden is het onverstandig om procesverbetering uit te stellen, of over te slaan als het ‘te druk’ is: ze kunnen er juist voor zorgen dat het Ontwikkelteam effectiever wordt. Het Ontwikkelteam kan, door het uitvoeren van de procesverbeteringen meer werk verzetten, waardoor velocity omhooggaat.  

3. Zeggen dat de velocity omhoog moet 

Gelukkig horen we dit weinig Scrum Masters zeggen, het is namelijk dodelijk voor de moraal van het Ontwikkelteam en hun performance op langere termijn. Zeggen dat de velocity omhoog moet komt vaak neer op zeggen dat het Development Team harder of langer moet werken, of de kwaliteit van hun werk (het product Increment) moet verlagen. Dit druist in tegen principes 8 en 9 achter het Agile Manifest: 
 
“Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.” 
 
“Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.” 
 
Dit is niet houdbaar, en zal er op termijn voor zorgen dat de velocity juist zal dalen. Dit kun je aantonen met een Causal Loop Diagram:  

4. Een Sprint Retrospective zonder Product Owner 

“De Sprint Retrospective is een kans voor het Scrum Team om zichzelf te inspecteren en een plan te maken om zichzelf gedurende de komende Sprint te verbeteren.” 
 
Het hele Scrum Team is bij de Sprint Retrospective, dat is inclusief de Product Owner, want: 
 
“Het Scrum Team bestaat uit een Product Owner, het Ontwikkelteam en een Scrum Master.” 

De Product Owner is eigenaar van de Product Backlog en verantwoordelijk voor Product Backlog management. Dit zijn zaken waar potentiële verbeteringen mogelijk zijn, en die dus onderwerp van een Sprint Retrospective kunnen zijn. 
 
Een uitzondering is een geschaalde omgeving. Als er meerdere Ontwikkelteams aan hetzelfde product werken, dan hebben zij dezelfde Product Owner. Deze Ontwikkelteams hebben op hetzelfde moment de Sprint Review en Sprint Planning, en waarschijnlijk dus ook op hetzelfde moment de Sprint Retrospective: 
 
“De Sprint Retrospective vindt plaats na de Sprint Review en vóór de volgende Sprint Planning.” 
 
Het is dan aan te raden dat de Product Owner elke Sprint bij een ander Ontwikkelteam aansluit voor de Sprint Retrospective, zodat elk Ontwikkelteam met regelmaat een Sprint Retrospective met de Product Owner heeft. 

4. Nooit naar de Definition of ‘Done’ kijken tijdens de Sprint Retrospective 

Tijdens de Sprint Retrospective wordt gekeken of de Definition of ‘Done’ aan moet worden gepast: 
 
“Gedurende elke Sprint Retrospective plant het Scrum Team manieren om de kwaliteit van het product te verhogen door de werkprocessen te verbeteren en zo nodig de definitie van “Klaar” aan te passen, mits zinvol en niet in strijd met de standaarden van het product of de organisatie.” 
 
De Sprint Retrospective is het enige moment waarop de Definition of ‘Done’ aangepast kan worden. Doordat de Sprint Retrospective na de Sprint Review en vóór de Sprint Planning plaatsvindt, is dit het enige moment  waarop er niet inhoudelijk aan het product Increment gewerkt wordt. Elk ander moment zorgt ervoor dat ‘de regels van het spel tijdens het spel worden aangepast’:

“De Definition of ‘Done’ […] helpt het Ontwikkelteam te bepalen hoeveel Product Backlog items zij kunnen selecteren tijdens de Sprint Planning. Het doel van elke Sprint is om Incrementen van potentieel opleverbare functionaliteit te leveren die voldoen aan de huidige Definitie van “Klaar” van het Scrum Team.” 
 
Een aanpassing van de Definition of ‘Done’ zorgt er vaak voor dat er per Product Backlog item meer moet worden gedaan om deze aan de Definition of ‘Done’ te laten voldoen. Het aanpassen van de Definition of ‘Done’ tijdens tussen de Sprint Planning en de Sprint Review (dus niet tijdens de Sprint Retrospective) kan er dus voor zorgen dat het Sprint Doel onhaalbaar wordt. 

Dit was de laatste blog uit de serie Pitfalls van de Scrum Master. 

Heb je vragen, of wil je doorpraten over een van de pitfalls van deze of een voorgaande blog?  
Laat dan een berichtje achter onder de LinkedIn post van deze blog, of bel 030 - 20 20 833. 

Stefan Kennedie

Stefan is een enthousiaste Scrum en Agile consultant en trainer die veel ervaring heeft in het trainen en coachen van professionals voor wie Agile en Scrum nieuw zijn. Hij heeft uitgebreide ervaring in het toepassen van Scrum bij organisaties buiten het IT-domein.