Team Retrospective Principles
A retrospective makes time for the team to reflect on recent activities and identify actions to improve their performance.
There are many ways to run a retrospective, and many resources to help you to discover and practice new methods. So how do you pick which methods to use?
If you focus on the principles underlying a good retrospective you can be flexible and try a variety of methods that are compatible with your principles.
So let’s first look at the purpose of a retrospective and then the set of guiding principles I use.
I have also included a skeleton method at the end of this post so that you get an idea of the format of a typical retro.
However: be flexible, be creative and try out a wide variety of formats – you don’t want your retros to become a stale ritual that your team endure each time.
What’s the purpose?
A retrospective is all about making time for continuous improvement, that is: maximising value delivery and minimising waste. By meeting periodically and using the right process the team can make a big difference to its performance.
In an Agile software development team a retrospective is all about finding ways to deliver more valuable stories with less waste (e.g. fewer defects, avoiding the wrong stories, less delay).
For a customer service team a retrospective could focus on how to achieve more high quality customer interactions (such as account management) and less waste in the form of defects, team turnover, mis-configuration and lost customers.
In more detail the purpose of a retrospective is to:
- commit the team to regular time for reflection and continuous improvement
- help the team find the right problems to face
- see the power they have to make progress
- help the team discover, plan and execute improvement actions.
Retrospective principles:
Here are the principles I find produce the best results:
- Aim for one good improvement action each retrospective, an action that is ready to make progress on right away, and with one willing owner
- Confidential, make a safe place to discuss tricky topics; what is said in the room stays in the room unless the team collectively choose to take it out
- Equivalence of team members, everyone in the retro has equal status in the room no mater what their status in the team
- Consent over majority, find a way to bring the team together under a common purpose, rather than a split team with many competing ideas
- Achieve a balance in the retro of quiet reflection, discussion, creativity and commitment to a way forward
- Independent facilitator, you need someone to keep the team to the agreed process, to ensure progress is made towards your objective, to ensure equivalence of the team members, basically to ensure that everyone keeps to these principles.
I encourage you to think about what your principles would be. First do take time to understand why the principles above are widely supported and what effect they have on the team and the outcomes of the retrospective process.
Some ideas on running a retrospective
Taking everything above into account, here’s a skeleton retrospective structure that you might find useful:
Initial admin:
- Check-in – Everyone around the room checks in with a few words on how they are doing today. “I’m good”, “I’m tired”, “My dog isn’t well”, …
- Quick summary of how the week/month went – “We delivered X stories”, “It was a challenging week because…”
- Review the current improvement actions – from previous retros
- Agree desired outcome of this retro – often just “find one good improvement action”, but this could be “explore why we haven’t made much progress on our current actions”.
- Agree today’s retro theme or format
And now the main part, very much shaped by the retro theme or format:
- Quiet reflection, everyone writes things on sticky notes
- Facilitator builds a shared understanding by reading out the stickies and asking for clarification
- The team chooses what to make progress on, with the help of the facilitator.
And finally, once the improvement area has been chosen, the hardest part:
- Quiet reflection, the team thinks up ways to make progress on
- the chosen area
- Share proposals, the team shares proposals, with the facilitator building a shared understanding
- Build consent, guided by the facilitator the team comes together under a single proposal, often by merging several related proposals
- Action, the team decides and documents the action, the owner, and the first step.
- Commitment, the team checks itself for commitment to this action.
On that last point the team is checking that it is being realistic. I would advise that the team bears this in mind during this last stage, e.g. the facilitator could ask in proposal generation, “Is this something we are going to be able to commit to?”
What theme for your retrospective?
But what about the theme or format? Here’s a great guide with lots of ideas: Agile Retrospectives: Making Good Teams Great
Questions, comments, feedback? Email me: eric@bn7.net