Retros are not continuous improvement
Retrospectives are one of the hallowed traditions of Agile software development. They are mentioned specifically as one of the twelve principles in the Agile Manifesto. They are one of only four regular activities prescribed in the Scrum guide. Extreme Programming says you must “fix XP when it breaks” (and talks a bit about retrospectives in that context, though it’s not super clear). Every Agile team and workplace I’ve ever encountered has had retrospectives. And everyone knows what this is all about, right? Continuous Improvement! That’s the holy grail, right? Kaizen! The true, pure heart of Lean and Agile. Kaizen means “change good”. And we’re all about changing, and improving, and growing, and learning, right?
Well, sure. But here’s the catch that nobody has been telling you: retrospectives are not continuous improvement.
What are retrospectives, exactly?
Retrospectives are a regular cadenced activity where a team pauses and reflects on how it is working and finds ways to work better. The Agile Manifesto says:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
That’s a pretty good way of describing them. So what’s the problem? There are two, really. Firstly, they are not continuous. Secondly, they are often not really about improvement.
Regular intervals are not continuous
If you’re doing something once a week, or once a month, or once a fortnight, that’s not continuous. That’s in fact called “discrete”, which is, in fact, the opposite of continuous. Continuous means “all the time”. Not some of the time, not part of the time, not once every now and then, but all the damn time. You never stop doing it. That’s Kaizen.
Retrospectives are often not about improvement
A lot of retrospectives just end up being whine fests. Which is actually ok. Sometimes people just need to vent. But the usual pattern of getting people to put stickies on a board, complaining about people or processes or tools, and then getting ignored or turned into some action item that goes nowhere, does not deserve the term “improvement”. (Remember, if you’re not coming up with concrete time-bound action items, assigned to real people and tracked, you’re doing it wrong).
But that just means we’re bad at retrospectives, right?
You might be thinking that this just means that someone is bad at retrospectives. There are bad and good ways to do retros, certainly. Some teams flounder about and yell at each other, don’t come up with action items, and/or don’t track them, and/or don’t resolve them. But this is a deeper problem. A problem with the fundamental structure and format of retrospectives. They are distanced from the problems, in space and in time. This drastically reduces their effectiveness. Continuous improvement happens everywhere, with everyone, all the time. It is a change in how people do work and function in an organisation. Not a special meeting you have once a fortnight.
Continuous Improvement is not what you think it is
Continuous Improvement is an old concept from Lean, not Agile, and it is not the same as doing retrospectives. It is a fundamental change to the structure and culture of work in an organization.
It is a responsibility of the whole organization
It is not something that scrum teams do once a sprint. It’s something that everyone practices all the time. Everyone in the organization has a responsibility to be continually improving their work, removing and fixing obstacles. Everyone from the lowest rung on the ladder to the CEO should be doing this. Technology, “business” (can we just get rid of that stupid distinction please?), marketing, procurement, everyone, everywhere, all the time.
It happens (pretty much) all the time
Continuous improvement does not mean that every now and then you stop doing whatever it was you were doing and think about how things were. That’s not continuous. Think about it this way: why are people bringing things up in retrospectives? Fixing things when and where they happen or go wrong is the best way to do it. Why weren’t they brought up at the time?
If someone in a retro says “staging environment went down last Wednesday, blocking our testing”, why wasn’t that brought up, discussed, fixed and permanently remediated last Wednesday? If someone says “the new approval procedure slowed down my hotfix”, why wasn’t the procedure challenged and improved or removed then?
Because it’s hard. Really hard. Most organizations aren’t prepared to do support this way of working. This is true Kaizen, Lean Kaizen, which I like to describe as “Stop and fix it”. If something is bad, or defective, or slow, or unnecessary, or wrong, then you all stop and fix it, then and there. Not in a week, not in a month, not as a post-it note on a wall three weeks later, right then and there.
Andon cords
In Toyota factories, they have these things called Andon Cords. If someone spots a problem on the line, they pull the Andon cord right away. The whole line shuts down. Everyone stops what they are doing and investigates and fixes the problem. And makes sure that it doesn’t happen again.
Think for a moment about your workplace. Imagine if every time someone encountered a stupid rule, an unnecessary process, a bad tool, a slow or buggy piece of software, they didn’t put up with it. They pulled the cord, they grabbed their team and their manager and said: “this isn’t right; we have to fix this”. And everyone stopped what they were doing and fixed it, for good. (And you know what they don’t do at Toyota? Sprint Retrospectives).
You’re probably thinking “That’s madness, we couldn’t do that! Nothing would get done!”. That’s the whole point, and that’s why nobody does this and why everything sucks. It is HARD. And for a while, a short while, nothing at all will get done. But things will start getting better as lingering problems get fixed, and fixed for good. And people will be able to get back to their jobs, but they will be operating in a different way: the Kaizen way.
It’s a Lean thing, not an Agile thing
Continuous Improvement is basically Kaizen, which is a Lean thing. And that means it’s an old Japanese manufacturing thing, not a new American software development thing. It’s also an organizational thing, not a project management or product development thing. It’s not just taking a traditional Waterfall PIR (Post Implementation Review) and doing it once a sprint. That’s a start and it’s a big improvement on doing a PIR at the end of the project (a bit late then, huh?). And props to the Agile Manifesto for at least mentioning this most basic manifestation of the spirit of continuous improvement. But it’s not enough.
One place I worked had a Kaizen scrum and a weekly standup around a board with Kaizen items. These weren’t things raised by a specific team but general organizational improvements. Obviously doing it once a week with post-it notes isn’t great, but it was a step in the right direction.
I still think we should do retros…
I’m not saying we should all stop doing retros. They are useful and have their purpose, even in an organization doing proper continuous improvement. And they can be an opportunity to think about how the team is getting along, to review metrics, to formulate experiments, and identify subtle long-running problems that never came up because they were never a sharp and immediate issue.
They are also a useful first step on the long and hard road to continuous improvement. And most companies in the world haven’t even taken that first step.
… but let’s not kid ourselves
They might be worthwhile and a good first step, but they’re not continuous improvement and they’re not Kaizen. Anybody who says they are doesn’t understand where these ideas came from. If you want to start learning more, I would recommend reading The High Velocity Edge by Steven Spear or Toyota Kata by Mike Rother.
