I have been thinking about retrospectives quite a lot lately. One reason for this is that I was fortunate enough to be asked to facilitate one as an external to a team. Another reason is that surprisingly often I hear people criticize them and there are few common arguments that I would like to address specifically.
A confession first: I fear facilitating retrospectives. Every time I go into one, I am afraid of what I might learn. At the same time, I love them. If a team finds even a single thing to improve then I feel that it was worth the time and effort.
One reason I find retrospectives so important is that to me, continuous improvement is a fundamental part of agility. The very first sentence of the ‘Manifesto for Agile Software Development‘ points this out:
We are uncovering better ways of developing software by doing it and helping others do it.
If we put emphasis on the word uncovering, then to me at least it means that we might not know yet what is the best way to do things, and we should regularly inspect our ways of working so that we can improve. But this is not easy, so I can understand why it can feel like a waste of time.
“Retrospectives are a Scrum thing”
As we started with the agile manifesto, I think we can continue with one of its 12 principles:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Yes, the term retrospective is made known by Scrum. If you are doing Scrum then, in practice, you have retrospectives (or you are not doing Scrum really). Retrospectives are Scrum’s way to ensure that the team gets better. But that does not mean that you can’t have them if you are doing something else. Call them whatever you like, have them when ever you can or need. But have them!
Teams that reflect and improve are less likely to make old mistakes. They get technically better, they get better at team work, and they get better in solving complex problems. Retrospectives help to waste less time.
Yes, retrospectives are a Scrum thing, but continuous improvement (through retrospectives) is an Agile thing.
“Retrospectives are just about complaining”
Some people feel that retrospectives are just a session for the team to vent and complain and nothing comes out from them. Sometimes this can be the case. For many teams, retrospectives are a safe environment where they feel that they can openly express their frustration, and this is actually a really good thing. But retrospectives are not just about complaining. One core aspect of retrospectives is to get concrete actions. If we are precise and follow the definition of the Scrum guide, these concrete actions are to be implemented during the next sprint:
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.
So, bringing out problems and complaining is something that happens during retrospectives, but this is not the only thing. A good retrospective always ends with at least one concrete action that can be implemented during the next sprint and then reviewed at the end of the sprint.
“Why can we only do changes every 2 weeks?”
At times, people who see retrospectives as a good thing still criticize them for being too slow and argue that changes should be done constantly and without any special sessions.
The Scrum guide (based on my interpretation) does not say to just have a retrospective once in a Sprint:
Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
Yes, the formal sprint retrospective session should be held at the same time, after the review, every sprint. But this should not limit you from making improvements continuously.
Another thing to consider is that development activities usually provide better results when you can focus on them, so why wouldn’t improvement activities? This brings me to Lean.
Lean thinking focuses on delivering value and minimizing waste. There is a really nice article (and video) about this by Agile 42 that gives a good high-level intro to the topic. One aspect of it is the different sources of waste, The 3 M’s: Muri, Mura and Muda. In this context, we are mostly interested in the last one, Muda, which means wasteful activities. Now, the best way to handle Muda is during work breaks, when the flow is stopped and everyone can come together and truly analyze the processes thoroughly.
So: a small change on the fly can be good, but if you take time to plan a change and also make that a goal for the whole team, then the results can be greater.
“Retrospectives cost money”
Retrospectives are a key to getting better results. Spending time (and money) on them can feel costly at first, but in the long run they can save more than they cost. Sure, you have a team that is sitting together and none of them are doing anything that produces concrete parts of the solution, but the findings that a retrospective produces can produce better working methods, which e.g. reduce throughput time, increase quality and decrease the solution’s lifetime costs.
Yes, retrospectives cost money. Not having them can cost more.
