Book references:
Essentially it is a chance to reflect and learn (historically called postmortem made to learn from failures)
Norman Keirth (Project Retrospectives: A Handbook for Teams Reviews author) Prime Directive
"regardless of what we discover, we must understand and truly believe that everyone did their best job he or she could, given what was known at the time, his/her skills and abilities, the resources available, and the situation at hand."
What happens during retros - the 5 steps
- Set the stage - getting ready (ex: create safety, I'm too busy)
- Gather data - the past (ex: artifacts contest, Timeline)
- Generate insigths - now (ex: fish-bone, 5 whys, patterns and shifts)
- Decide what to do - the future (ex: Making the magic happen, SMART goals)
- Closing the retro - retro sumary (ex: what helped, what hindered, delta)
Stories from the trenches
- We should never impose retros on people not wanting retros... it never works!
- There is a difference between retros and discussions at the cafeteria: for retros, you have (or need!) shared commitment to find solutions.
- Serves to celebrate good things as well.
- Serves as points to evaluate where we are going
Esther Derby's (Agile Retrospectives author) findings
retros can be :
- boring
- painful (ex: finger-pointing) to the point people want to stop them
those 2 issues come from a lack of :
- focus
- participation (thus the need to set the stage properly)
- genuine insight (you can't only do start/stop/cont because they only show symptoms... what is the root cause behind the symptoms)
- buy-in (takes a genuine facilitator - never the team leader - has to be neutral to the team, ideally from another team)
- follow-through (followup is key otherwise, this is a lost of time)
More stories
- 30 minutes is the shortest retros possible (for a team that knows exactly what to do) - typically, minimum of an hour.
- Finger pointing is a retrospective killer... a key to get out of this pattern is to change subject
- Ground rules are really useful to put constraints on how retros are conducted (no naming no blaming rule for example - interpersonal issues shall not be addressed in retros but by management in parallel)
No naming, no blaming!
people, like kids, respond in much better ways to positive comments than negative comments. Negative comments leads to bad team work and eventually bad results! See the Prime directive again and how it actually helps with this essential ground rules.
Identify changes
It is not enough to reflect, you need to take actions to change things. Use SMART goal and name a responsible to follow up on each goal:
Specific
Measurable
Attainable
Relevant
Timely
You start the next retros by asking how we are doing with regards to previously set SMART goals.
Don't "sell" retros, instead
sell a way of learning how to:
- avoid repeated mistakes
- identify and share success
Take away:
If you leave out a step in retrospectives, you will make problems emerge that you do not understand fully nor find solutions to.
Good article Steve,
ReplyDeleteI hope that this will convince many people on the benefits of Retro. Retro are necessary for a team to grow. Most teams here either don't perform any retro or do it poorly.
Thanks; I agree, it seems we have a lot to learn in this area... let's start!
ReplyDelete