De vorige blogs gingen over de pitfalls bij de Product Backlog, de Sprint Planning, en de Daily Scrum. Vandaag gaan we verder met de pitfalls tijdens de Sprint.
Pitfalls tijdens de Sprint
Het hart van Scrum is een Sprint, een timebox van één maand of minder waarbinnen een “Klaar”, bruikbaar en potentieel te releasen product Increment wordt gecreëerd door een Ontwikkelteam.
1. Het Ontwikkelteam vertellen hoe ze hun werk meten doen, of wie wat doet moet doen
De Scrum Guide is hier heel duidelijk over:
“Ontwikkelteams worden door de organisatie zodanig gestructureerd en voorzien van bevoegdheden dat zij hun eigen werk kunnen organiseren en beheren. […] Niemand (zelfs de Scrum Master niet) vertelt het Ontwikkelteam hoe zij de Product Backlog moeten omzetten in Incrementen van potentieel uitleverbare functionaliteit.”
Het Ontwikkelteam bestaat (als het goed is) uit professionals die zelf prima weten hoe ze hun werk moeten doen. Daniel Pink heeft in 2009 zijn boek “Drive: The Surpirising Truth About What Motivates Us” uitgebracht. Hierin baseert hij zich op diverse studies over motivatie en prestaties. Motivatie komt voort uit drie aspecten: autonomie, meesterschap (mastery) en het hebben van een doel (purpose).
Autonomie haal je bij een Ontwikkelteam weg als je ze vertelt hoe ze hun werk moeten doen, of wat ze moet doen. Meesterschap kun je als Scrum Master ondersteunen door ervoor in te staan dat het Ontwikkelteam tijd krijgt om zichzelf te verbeteren. Het hebben van een Sprint Doel (zie Scrum Master pitfalls bij de Sprint Planning) en een Product Owner met een Visie (zie Product Owner pitfalls bij de Product Backlog) helpen met het geven purpose.
Er staat een mooie animatie over het boek van Daniel Pink op Youtube die ik van harte kan aanbevelen:
2. Beslissingen nemen voor het Ontwikkelteam
Ontwikkelteams zijn zelforganiserend. Als je beslissingen voor een ervaren Ontwikkelteam neemt, ondermijn je hun autonomie en ontneem je een deel van hun zelforganisatie. Dit zullen ze waarschijnlijk niet waarderen, en kan ten koste gaan van hun motivatie (denk aan Daniel Pink van hierboven). Het is ook gevaarlijk om beslissingen voor onervaren Ontwikkelteams te nemen. Onervaren Ontwikkelteams moeten vaak nog groeien in hun zelforganisatie. Wanneer jij als Scrum Master beslissingen voor ze neemt, ontneem je ze de kans om die keuze zelf te maken. Ze raken er dus niet aan gewend, en het zal langer duren voordat ze als een zelforganiserend team werken. Waarom zelforganisatie zo belangrijk is heeft David Marquet krachtig uitgelegd, ook hier is een mooie animatie van te vinden op YouTube:
3. Geen aandacht besteden aan verbeterpunten uit de Sprint Retrospective
Misschien heb je het wel eens gezien, een Ontwikkelteam dat tijdens een Sprint Retrospective geweldige plannen heeft om te verbeteren, maar zodra de volgende Sprint start weer gegrepen wordt door de realiteit (en druk) van elke dag. Aan het eind van de Sprint is er niks van de verbeteracties terecht gekomen, met als gevolg dat het team niet beter wordt. Merk je als Scrum Master dat het Ontwikkelteam geen tijd besteedt aan de verbeteracties, vraag er dan vooral eens naar. En zorg ervoor dat er tenminste één verbeteractie op de Sprint Backlog staat:
“The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.”
De volgende keer gaan we verder met SM pitfalls bij de Sprint Review. Heb je nu vragen over, of wil je doorpraten over een van bovenstaande pitfalls?
Laat dan een berichtje achter onder de LinkedIn post van deze blog, of bel 030 - 20 03 627.
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.