Earlier this year I met David Horowitz at the Retrospective Facilitators Gathering, a yearly event where people exchange their experiences with Agile Retrospectives. We had some great discussions about increasing the value with continuous agile retrospectives and which exercises you can use with co-located and distributed teams. And we agreed that David would write a guest blog post for benlinders.com :-).
David is the CEO and Co-Founder of Retrium who recently released a first version of their retrospectives tool. In his guest blog post he explores how you can use agile retrospectives for continuous sustainable improvement.
Continuous Improvement
I’d like to start by asking you two questions:
- What’s the goal of running a retrospective?
- How often do you run them?
If you’re like most people, your answer to the first question was “to achieve continuous improvement” and your answer to the second question was “at the end of every sprint.”
Think about those two answers for a moment. Is it even possible to achieve continuous improvement if you only run a retrospective at a certain predefined interval? Doesn’t the word “continuous” require a nonstop, unending process?
An Alternative to the Sprint Retrospective
For longtime proponents of retrospectives, the Scrum framework has been both a blessing and a curse. A blessing because it has popularized the retrospective concept itself. Thanks to Scrum, more people understand the value of inspecting your team’s practices and looking for ways to improve. A curse because it has made the retrospective synonymous with the sprint retrospective.
Why is that a bad thing? It’s bad because there are many other types of retrospectives that few people are paying attention to! Ever heard of a “post mortem”? In some ways, that’s simply a project retrospective. There are also personal retrospectives, organizational retrospectives, and the one I’d like to focus on today: continuous retrospectives.
Why Continuous Retrospectives?
At this point, you might ask yourself: why do we need to run a “continuous” retrospective? Isn’t once every few weeks enough? To which I’d reply: what does your team do today if it identifies a pain point early on in a sprint? Does it immediately try to fix it? Or does it wait until the end of the iteration to give it attention?
If your team is like most, it probably did the latter. And think of all the time wasted! Imagine if you came up with your idea for improvement on the first day of a new 2-week sprint. How much time could you have saved by raising the issue immediately rather than waiting a few weeks for the scheduled retrospective? That’s where the idea of a continuous retrospective comes in.
How to Run a Continuous Retrospective
By continuous, I certainly don’t mean to imply that your team should constantly be sitting in a room running Lean Coffee or 4L. Instead, continuous retrospectives rely on different techniques to be effective.
The one I like the most is through the use of a modified kanban board. Take a prominent spot on your team’s wall and put up the columns: Ideas, Doing, Done. Whenever you have an idea for improvement, immediately write it down on a sticky note and put it in the “Ideas” column of your board for everyone on your team to see. If you want, write your name down so people will know whose idea it was.
If you’re confident in your idea and want to start working on it right away, immediately move it to the “Doing” column. More likely, you will want to get some feedback from your team before trying to work on it yourself. If that’s the case, use the Daily Scrum to mention your idea to your team and ask anyone who is interested for a breakout session after the Daily Scrum is over. If it’s a good idea, people will jump at the chance.
Achieving True Continuous Improvement
Continuous retrospectives are not incompatible with sprint retrospectives. In some ways, sprint retrospectives become even more useful if your team is thinking about how it can improve throughout the sprint. That’s because by the time you’re ready for your sprint retrospective, your team will have already generated a number of ideas for improvement. The sprint retrospective can then be used to go over these ideas, prioritize them, and pick the best ones to try to work on in the next sprint. Continuous retrospectives can therefore make your sprint retrospectives more focused.
Put another way, if continuous deployment is a “zen” state for programmers and product managers, shouldn’t continuous retrospectives be the “zen” state for Scrum masters? More succinctly, if retrospectives are supposed to drive continuous improvement, shouldn’t they be run continuously?
David Horowitz is the CEO and Co-Founder of Retrium, a tool that makes retrospectives for distributed teams easy and effective. It implements a number of the most popular retrospective techniques, including 4Ls, Mad Sad Glad, and Start Stop Continue.
The Why and How of Agile Retrospectives
This guest post from David Horowitz inspires you to use agile retrospectives for continuous improvement. To make retrospectives stick in organizations and get more business value is important to know why you are doing retrospectives and use appropriate exercises in agile retrospectives. The book Getting Value out of Agile Retrospectives from Luis Gonçalves and Ben Linders provides many different retrospective exercises that you can use to design effective retrospectives for continuous sustainable improvement.
