As part of my back to basics series I wanted to spend some time on the topic of Retrospectives, otherwise known as Introspection or Reflective Improvement sessions.
If the Stand-up is the bread, then the Retrospective is the butter. It is simply just one of the most fundamental elements of doing/being Agile there is. Alike Stand-ups, they are just as easy to be ineffective.
At its most basic process this is how to run a retrospective:
- Get the core team together
- Give the core team 10 minutes to brain-storm their thoughts on how the last Sprint/<insert cadence cycle> went in terms of:
- What is working well?
- What to do differently?
- What still puzzles us?
- Group like thoughts together
- Choose items to focus on and address
- Make actions
Let’s break these items down a bit more:
Get the core team together
It doesn’t have to be in a meeting room. It can be in the pub or in a park. In fact, the team don’t even physically have to be together – you can do retrospectives virtually using a tool like LinoIt. What is important here is that the team needs to feel safe to speak freely and that there is an environment where there are no elephants on the room. If you have a Project Manager or a Product Owner that will not be conducive to such an environment then you have a bigger problem here – re-focus the retro on getting this fixed!
Brainstorm for 10 mintues
There are five points I want to make on this sub-activity:
- The duration to reflect on is not important, but framing and frequency is. Retrospecting once every three months is not being Agile. The more frequent you can do this activity the better. Keep in mind, as you increase the frequency you may need to spend less time doing this activity – ie if you choose to retrospect each day then it could be a ten minute activity.
- Ensure the brain-stormed items are put on a single post-it note and are clearly legible so that you can take a photo of it later. There is nothing more annoying then spending time capturing/documenting the retrospective. Take a photo of the outcomes and stick the photo on your team’s wiki.
- I sometimes like to add a fourth item, “Lessons learned”. I believe that celebrating what we have learnt together as a group is very powerful and enables both sharing of information and a recognition that we aren’t perfect and it is a good thing to always learn.
- Sometimes people like the second question to be phrased as a negative and not solution focused question – ie “What isn’t working well?” vs “What to do differently?”. The benefits of the “What isn’t working well” approach is that it doesn’t assume root cause and leads to potentially better solution analysis later within the retrospective. The downside is that for the people that aren’t good with dealing with criticisms this can sometimes be confronting. I don’t think it matters which you choose, just be aware of the risks given the wording and work out which format better suits your team.
- The focus on the reflection is not what was produced but how the team worked together to deliver.
Group like thoughts together (affinity mapping)
Notice that I didn’t say how to do this? That is because your mileage may vary based upon your approach. The Scrum Master can do this once everyone has written their thoughts, or the core team can do it themselves – either one at a time or as a collective. You can read them out or get the team to quietly read it themselves, the options are really endless. My personal preference is to get the core team to affinity map themselves and then to verbally skim through the non grouped items and spend more time on the strongly grouped themes. Items under “What still puzzles us” should be answerable on the spot or may become a focus area.
Choose items to focus on and address
Usually I would choose the strongly grouped themes but there is a risk that you miss something important that can significantly improve your ability to deliver as a team. What is important is that the items you choose to focus on are the ones that will result in marked improvements for how the team will work together.
It is a rookie error to focus on ten things within a single retrospective. If you have two weekly Sprints, you ideally don’t want to focus on any thing more than three (five at absolute tops) actions. This is because you want to ensure that you are making changes and if you have too many actions then nothing will change and then you will loose all support from the team for doing this practice in the future.
Who makes the suggestions of the changes? The core team does. It shouldn’t be the Scrum Master who is imposing change on the team, it should be the team embracing an environment of continuous evolutionary improvement.
Make actions
So along with only having three actions you want to ensure that these actions address the root cause of the problem (ie you are not solving the wrong problem), that the actions have clear owners, dates (if possible) and value.
The best actions I have ever seen out of a retrospective are ones that the team writes as stories and then feeds the stories back into the release or sprint backlog – ie they get treated like everything else. Because they are treated like everything else they get a priority and estimate which means that they have to have value as agreed by the whole team in order to work on them in the current Sprint.
If you aren’t going to write them up as stories and add them to your backlog(s) then make sure the first step you do in your subsequent retrospectives is to review previous actions. It is a smell when actions get carried over from retrospective to retrospective – it is symptomatic of items that weren’t perceived as important or that the team feel that continuous improvement is not important.
Conclusion
Software development isn’t simple. The only way that we can improve in the complexity that we are working with on a day to day basis is the reflect and adapt. Sprint Planning and Sprint Reviews are the way in which we reflect and adapt the work we are doing. Retrospectives are the way we reflect and adapt how we are doing our work.
Agile Forest 