Sometimes, development teams can become stuck in their train of thoughts or have a hard time to find ways to improve their workflows. At other times, your teams are just tired and switch to autopilot when thinking about what went good and where is room for improvement.
In either case it is time to mix it up.Why not give it a shot to look ahead instead of behind?
A Pre Mortem is classically a project management tool for risk management and analytics. At the beginning of a project, key stakeholders, managers and all others come together and imagine that their project failed. Now they have to answer the question “why did that happen?” and in a next step “what can we do about it?”.
This technique can be scaled down to fit into an Agile environment. The question I raised to a Scrum development team for example was: “Imagine that your next sprint ruined. What were the reasons?”. This post describes the technique used and the experience. (Spoiler: “Good – with room for improvement.”)
Since this post was created the Pre Mortem Retrospective was repeated already and the conclusions are still valid and confirmed.
The development team at hand is very experienced, working together on a tough project. The project follows Scrum methodologies with four different development teams. I was involved as Agile Coach and support for the Product Owners and Scrum Master. In this role I took over moderation of Scrum Events on an irregular basis.
I asked the four team members if they would be up for an experiment. On the plus side, they would get something shiny and new, on the downside I could not predict whether something useful would come out of it. As the input was very positive I went ahead and planned a Pre Mortem Retrospective.
Planning the Pre Mortem Retrospective
I will not go into detail on how to set up and execute a Scrum Retrospective at this point. If you need inspiration, I highly recommend clicking around in the retromat. If you need guidance on how to set up a retrospective in general, drop a comment below – this will influence my backlog directly! For this Retrospective, the data gathered and the issues, actions and conclusions discussed were different from a classic version.
The setup for the actual Pre Mortem part of the Retrospective looked as following:
- Everyone writes up one to three events which you think will ruin the sprint for your team.
- Everyone introduces their event to the group (and everyone collect doubles if you have them).
- The event with the most mentions is now the benchmark-risk: The group should discuss roughly how likely it is to happen.
- The other risks get mapped in relation to each other: “Is it more or less likely than the stories already mapped?”.
- Dot-voting: Each team member receives three stickers which she can distribute on the events mapped out according to the perceived severity.
- The group discusses one evasion and two reaction plans for the most likely events which received more-than-average dots
The Results, Feedback and Learnings
The team was able to correctly predict two events which would have put the sprint goal (or at least their weekend) at risk. It allowed the team throughout the sprint to react with a calm head. After the sprint I interviewed the team on whether they would want to repeat it and the answer was a clear: “Yes, this is something we should do from time to time again.”. Overall, a lot of information was generated about the next sprint and about the process as well:
- A change in perspective helped the team to look at ongoing issues differently – some risks identified were identical to past topics, the focus on “how will you react” helped the team act calmer.
- The changed focus within a retrospective needed way more framing and explaining than I anticipated. The next time, the teams will get a deeper introduction on what to expect beforehand.
- A high focus on risks did not give enough room to talk about positive expectations. Future experiments will try to counter this aspect to help the team realize the good work they will do in the next sprint in addition to purely talk about negative events.
- It is not easy for a development team to activate the plans in the heat of an upcoming issue. The Pre Mortem needs to be well documented. My goal with this is to have a catalogue of potential issues and their respective action points for the teams.