“Retrospective” means “looking back”. Looking back is exactly what is done in a Scrum Retrospective. In my experience, this event is one of the most discussed topics in Scrum. This article goes over what Retrospectives are, why they are worthwhile doing and what arguments exist for when Retrospectives are put into question.
It is in the core interest of product managers that their teams not only keep their performance but identify potential risks. Then the teams need to have the opportunity and duty to work on the identified topics.
Agile Coaches and Scrum Masters fight to the blood for having Retrospectives while classical project managers and even some sponsors (or clients) look closely at them in their search for savings. Before looking at the question why a manager wants Retrospectives, let’s do a brief recap on …
What a Retrospective Is
A Retrospective is a timeboxed event which is done once per sprint. It is structured around improving the coming sprint, based on the learnings from the past one. Its agenda is:
- Identify what went well and should be kept
- Identify what needs to change and how
- Identify what needs to stop and should be dropped
While these sound like important points it is also understandable why it’s so heavily discussed. The purpose of a Retrospective by its very nature is to iterate not only on the software but on the process and work environment as well.
Why Retrospectives Are Heavily Discussed
The reasons I heard most when people (“the critic”) want to cut Retrospectives can be summarized in two statements, both taken from real-life projects:
- “Things are running well! We can stop wasting our time with them.”
- “We don’t have time for this! In the coming sprints, we need to have every minute on development.”
It is important to keep in mind that the analysis within those and similar statements are often true. There are lots of sprints with little time, team performance can be very high, a deadline might be due – reasons enough to just try to create more time to be productive, right?
On the other hand there is a long list of reasons why the critic should be interested in keeping Retrospectives. More important: You can help them come to that conclusion on their own. Before trying to jump into a fight, it might be a good idea to understand the truth within the arguments and how the Retrospectives connect to them.
Argument: Retrospectives Use Time
Well, duh. While this statement is, of course, absolutely correct, the drawn conclusion is wrong: Every kind of work suffers from the law of diminishing returns. With this in mind, Retrospectives can be seen as a constructive way of integrating controlled slack time into the sprint routine of a team. This means that even without any output, just giving the team controlled breathing room is most likely as beneficial as the extra development time, as long as it is kept timeboxed. Note that this argument does not include any output generated within a Retrospective! Everything actually created within a Retrospective comes on top.
Argument: Team Performance Does Not Increase
After a steady increase in for the first sprints, now the team seems to have hit a wall. This must mean that the Retrospectives are useless, correct? Well, with the same argument one could say that there is no use in eating anymore as I didn’t starve in the last six weeks.
It is actually already a feat for a team to keep up an increase in . This is something that needs a lot of discipline and energy. You should point out to the critic that a team that is sprinting on its perceived maximum capacity is nothing less than extraordinary. This team especially needs the space to identify all issues which might put their achievement in danger.
Retrospectives give a long list of benefits. What is even more awesome: Their impact can be measured. The factors that Retrospectives influence should be: Collaboration, and Satisfaction. Those three fields are naturally connected but each in its own brings benefits to the , the production team and the company overall. There is a high chance that you can not only name a key value which benefits through Retrospectives but you can also find a metric on how to quantify it.
- Knowledge Share: Team learnings are fed back from the development team towards the rest of the Scrum team, even the organization. Potential metrics:
- Ramp-up time of teams that had close contact to the team doing Retrospectives
- Amount of unresolved dependencies outside of the development team which the team could not resolve on their own
- : Both short- and long-term depend on the capability of the team to find roadblocks and potential for improvement. The Retrospective is the only time where this is done systematically with support by a moderator (usually the Scrum Master). Potential metrics:
- delta per Sprint (check for correlations with duration, number of participants, etc)
- Long term development, if comparable with other teams
- Morale: Often overlooked, happiness is a key ingredient to an efficient team. And it helps to share doubts and see that they are taken seriously. Potential metrics:
- Amount of HR complaints and feedback (careful, can be mixed up with level of trust in the organization)
- Many more
How To Talk About Retrospectives
“A good Retrospective will benefit your team both short- and long-term”. This is the basis of any argument in favor of them. Now it is a question on how to create awareness and acceptance for this statement. One crucial aspect for this is to keep in mind, that the critic is often right in many aspects. Her reasoning and worries are, in my experience, well grounded in reality. Only the conclusion that gets drawn is often flawed (Note: If the conclusion turns out to be correct or it sounds very reasonable, you should listen and evaluate how your team can benefit from the input). The flawed conclusion is often based on a misunderstanding of the potential and factual benefits achieved by Retrospectives. To re-align the conclusion, do not let the discussion revolve around the topic how the time could be spent.
Instead, focus on the benefits your critic and you both want to achieve. Create alignment on the goals and check how Retrospectives can help achieve those. Then you can work, together, on ways to maximize the Retrospectives impact towards those goals.
Should this reasoning fail, then agree with the critic on metrics to quantify the expected impact of your teams Retrospectives. You should avoid falling back to subjective arguments – and you should not accept if your critic does it. For any argument the follow-up question should be: “How do we measure this?”. In my experience, the burden of coming up with those metrics is best put on the person who wants to establish change.
If you’re already doing Retrospectives, ask the critic to give specifics on how you can proof to them that the Retrospectives are, in fact, time well spent. Encourage them to describe a scenario and provide metrics which would convince them to actively support Retrospectives. Do not forget that the critic is putting energy and effort into changing a process. This is something you should not take for granted. It is worthwhile to try to win over this energy for the future as your product will benefit through supporters like this.
On the other hand, if you are the one trying to set up Retrospectives, you need a way to proof that they are beneficial. A good approach is the (classical agile) offer to just give it a shot for a few sprints. As metrics, you can provide the amount of issues identified, amount of roadblocks removed, team satisfaction indices, and anything else that you can agree upon with the critic. Once you manage to add an objective component to the discussion it’s all a matter of measuring – and adapting.
One last word: Should the metrics show that you erred, then this is good for your product as well. It is now the best time to adjust the process and change the Retrospectives into something that has the expected impact. Should this be the case, do not forget to thank the critic – she just helped you optimize your team in one of its most impactful aspects!
A proper Retrospective is something that your product will benefit from – no exceptions. This is because it’s part of the definition, not because it’s so simple. Taking a few hours from a whole team regularly without a direct impact is something that comes under critique very easily.
Once you have found a lever to make the benefits transparent, push it permanently. Make it part of your routine to not only talk about the latest build and coolest feature but also add how the team improved and the hurdles they took, basically on their own. With time and success, the acceptance for Retrospectives will come. Just keep in mind that establishing good Retrospectives is a process in its own: It’ll take time, there will be mistakes, there will be setbacks – and there will be lots of small successes which you can bring out and use as motivation and guidance. It’s all about building a better product in the end.
It would be awesome if you’d take the time to drop me a note on how Retrospectives went for your team and how your product benefited – or suffered! – from doing them. What does prevent you from doing them regularly? What is a strong opinion you managed to (not) change?
“Let us cultivate our garden.” ― Voltaire