8,4 / 10 187 beoordelingen op Springest
030-2308900 info.nl@inspearit.com

Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 6

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.


DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 4

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls tijdens de Sprint Review.

    Lees verder
  • Opleiding toegelicht - Advanced Scrum Master

    Onlangs heb ik samen met collega Ruud Bruls voor de tweede keer dit jaar de tweedaagse training Advanced Scrum Master gegeven. Dit is misschien wel de leukste training die ik bij cibit academy geef.

    Lees verder
  • Veel voorkomende pitfalls waar scrum masters intrappen - Deel 3

    Een dagelijks terugkerend ritueel, de Daily Scrum. Een zeer waardevol moment mits het goed wordt gefaciliteerd.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 5

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls tijdens de Sprint Retrospective.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 2

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls bij de Sprint Planning.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 1

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls bij de Product Backlog.

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 4

    Help je Ontwikkelteam om de Sprint goed uit te voeren. Als Scrum Master moet je veel dingen doen, maar soms ook dingen laten.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 3

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls tijdens de Sprint.

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 5

    Hoe kun je het beste terugkijken op de productontwikkeling? Bekijk de tips om een goede Sprint Review te doen.

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 1

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in de Scrum Guide, een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is echter een stuk lastiger. 

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters intrappen - Deel 2

    Hoe zorg je ervoor dat je als Scrum Master de Sprint Planning goed onder controle houdt?

    Lees verder
  • Agile buiten de IT wereld

    De term Agile komt uit wereld van de software ontwikkeling, maar het gedachtegoed is de IT inmiddels ontgroeid blogt Stefan Kennedie. Waar wordt agility inmiddels toegepast? Is dat alleen in ons werkende leven, of ook al daarbuiten?

    Lees verder

Cookies op de website van Inspearit

Wij plaatsen functionele cookies, om deze website naar behoren te laten functioneren, analytische cookies waarmee wij het gebruik van de website kunnen meten en cookies van derden voor het weergeven van emdeded media (YouTube en GoogleMaps) Hieronder kan je aangeven welke andere soorten cookies je wilt accepteren:

Meer informatie