Many Agile approaches, such as Scrum, have a focused event (the retrospective) to reflect on the team’s performance and look for ways to improve. However, I’ve often found that this is the first event that teams want to drop. I’d like to lay out some of the reasons for this, possible ‘fixes’, and finally some alternatives if a team really doesn’t want to hold regular retrospectives.
Before we dive into the reasons, let’s start with understanding why we have retrospectives.
“At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.”
(Principle from the Agile Manifesto)
Simply stated, a team that doesn’t think about how it is doing work, and then attempts to improve, simply will not improve. While the principle doesn’t mandate the practice of retrospectives, Agile teams should be attempting to constantly improve in some manner.
And, if you’re taking a Lean approach, then a key principle is to perfect the value creation process by reducing waste and increasing efficiency. You’ll often hear of Lean teams implementing the concept of Kaizen; small, continuous improvement.
OK, so why would I want to drop my retro?
Good question! Why would you? My personal bias is that you would never want to do this, and yet teams regularly choose this as the first event to drop. The rationale most often cited is we never seem to improve and the time to go through a retro isn’t worth it. In general, there are three reasons why the time invested doesn’t seem to be worth it.
First, retros are often facilitated using the typical what is “working well” or “needs improvement” format. The simple +/∆ format doesn’t help a team find root-causes to the problems they identify; these are usually only symptoms.
Second, the team doesn’t check to see the results of their actions. No one volunteers to lead the action and, even if they do, there is often no follow-up after completion. Without follow-up, a successful action won’t get ingrained and old habits will take over.
Third, retrospectives may get boring and stale. Without changing the activities done in a retrospective, it will feel as though people just create the same laundry list of problems every time.
How do we fix this problem?
Let’s start with the retrospective itself. Start with a structure that leads to more detailed analysis of the problems identified. The process described in Agile Retrospectives by Esther Derby and Diana Larsen does a fantastic job of establishing a process that a team can use to get to actions they can take based on root-causes. This process also allows a variety of activities to be selected for the steps in the process. The book contains several techniques and you can find even more on Tasty Cupcakes or the Retrospectives Wiki.
Now, to ensure the actions take place and we follow-up on them, make these a part of your other events. Actions should be discussed and prioritized in Sprint Planning sessions so the amount of capacity the team will focus on improvement is known. When it comes time to review the work, the results of the actions should be reviewed as well. This information can then feed directly into the next retrospective.
What about more mature teams? Do they need retrospectives?
Very mature teams often find they evolve to handle issues that come up immediately as they happen. Essentially this is like the “stop the line” mentality in the Toyota Production System. Teams that do this may, or may not, still have heartbeat retrospectives to ensure they dive deeper into root-causes.
Another approach is to use A3 Reporting. This is a Lean thinking technique that has one or more people identify the problem, research its root-causes, identify possible solutions, and select one. A3 reports require approval (by a manager at Toyota, perhaps by the rest of the team, for changes to the team’s work system). This approval is used to ensure that all the appropriate stakeholders have been consulted, including those external to the team.
In a nutshell, it is possible to drop the retrospective ceremony, just not its intent since it is a core factor to a team’s inspection and subsequent adaptation.