Improvement Boards

The original version of this post had the tag #NoRetrospectives in the title, but I got tired of the flak and removed it. My intent was to be a bit provocative and to get people thinking about how we can do better than a biweekly retrospective. That is, This article is not advocating that we should stop improving. Rather, I’m arguing that we don’t go far enough. Let’s replace—or at least augment—the once-every-two-week “retrospective” meeting with a continuous process that’s part of our culture.

I recently hit on the idea of an improvement board to help with that. Let me explain.

Kaizen

Kaizen—continuous improvement—is central to Lean thinking. The notion is epitomized in Toyota's famous Andon Cord. A worker—any worker—pulls the cord when a defect appears or something goes wrong on the assembly line, and the entire line stops. That action triggers a flurry of activity, not so much to fix the defect (though they do do that), but to figure out why the problem occurred and fix the root cause. The goal is to dynamically change the manufacturing process so that the problem can't happen again, not to fix a single defect. You don't report the problem up the hierarchy. You fix it. Workers are constantly vigilant, addressing problems the instant they occur, not every two weeks, but all the time. More to the point, this thinking infuses every corner of Toyota's culture. Kaizen is something that everybody does every hour of every day.

Mike Rother's excellent book Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results dives deeply into Toyota’s thinking and practice. Here's the kata in a nutshell: Assess what you're doing and identify a long-term goal for improving. Figure out an intermediate step—something you can actually accomplish in the short term to move in the direction of your improvement (not arrive, just move). Identify three practical things you can do right now to get to that intermediate place. Do them. Repeat forever.

Put the list of practical actions on a physical board, and add one every time you retire one. The idea is to keep up a continuous flow of small improvements moving towards a larger goal.

Retrospectives

Moving to Agile thinking, the retrospective is our embodiment of Kaizen, and it is the core Agile practice. In fact, the retrospective is the only concrete practice that's mentioned in the Agile Manifesto's Principles: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If you don't take process improvement seriously, you're simply not Agile in any meaningful sense. The retrospective is the only required practice in Agile. Everything else derives from that.

My problem with the Manifesto's statement is the "at regular intervals" part. Stopping and reflecting every so often is not a bad idea, but it doesn't go nearly far enough. Kaizen is not a meeting. It's a bedrock everyday practice that infuses everything we do. You don't improve once every two weeks at the end of your sprint. You do it all the time. Delaying a fix until your next retrospective just perpetuates the harm.

We can, of course, apply Andon-cord reasoning to software. When you see something wrong, stop what you’re doing and fix the problem. Replace that once-every-two-week retro with continuous micro-retros. There are some situations where a formal retro may be useful—when a problem spans teams, for example. That can be the exception, however, not the norm.

So, instead of retros, think of a continuous-improvement culture. But, how do we build a strong culture of continuous improvement?

Impediment boards

A lot of teams use an impediments board to address this problem. Put up a sticky for everything that prevents you from working as effectively as possible. Retire at least one of these items every iteration. It's essential that the board be a physical board, out where everybody who can do anything to eliminate the impediment can see it. I've seen too many impediments lists buried in a Wiki or in Jira be entirely ignored month after month. Hiding this list inside a computer defeats its purpose. Managers never log on to Jira to look at it. It's the place where solutions go to die.

The other main problem with an impediments approach is that putting a note on the board is effectively pulling the cord, but all too often, nothing happens. Work doesn't stop. The problem isn't fixed. Many organizations with impediments boards use them as a way of putting off the actual improvement, as if recognizing the problem is good enough. Their inaction implies that getting rid of a productivity-sucking practice isn't as important as programming, or mind-numbing meetings, or other activities that aren't nearly as important. These impediments are killing your productivity, however. They prevent you from doing the "real work" that's supposed to be more important. We need to get rid of them right now, not at some indeterminate time in the future. If you have more than a handful of items on the board, you're not taking improvement seriously.

The improvement board

Which brings me to the improvement board. The idea is to encourage continuous improvement by integrating it into everyday thinking. The focus is on solving problems—actually making improvements—not just identifying them.

Every time you make an improvement, no matter how small, put up a sticky describing that improvement. Every tiny improvement is a win. Put it on the board. Periodically (instead of your normal retro?) gather around the board and discuss/explain. The stickies are anonymous. We want to encourage a culture of improvement, not pit team members against one another. If a good-natured competition arises for adding as many improvements to the board as possible, so much the better. If we improve 50 things this week, there's pizza for everybody!

Of course, keeping an impediments list isn't a bad thing, provided that you act on that list. An occasional retrospective where the team solves team-level problems that an individual can't recognize or address is also essential. Just get together at your desks when a team-level problem surfaces and solve it. Don't wait for a formal meeting. The more you focus in continuous improvement, however, the fewer formal retros you need.

For huge organizational problems that can't be addressed at the team level, The organization needs to stop work entirely and have everybody focus on finding a solution. Pull the Andon Cord. Really pause. Take a day or two. Do it off site where there are no distractions. Think deeply about the problem. Focus on putting solutions in place, not just identifying issues. (This was actually the most common form of retrospective when the Manifesto was written. We called them retreats, or if they were at the end of a project, postmortems.)

To sum up

Improvement is something we should do all the time, not once every two weeks in a retrospective. When a problem emerges, don't wait. Fix it. Do everything you can to instill a culture of continuous improvement throughout the organization. An improvements board is one way to do that in the small.