I sometimes get asked by managers if they should add the action items created in their team retrospective meetings to their kanban boards. More explicit management of retrospective outputs happens when managers start getting unsatisfied with their teams’ progress at improving their metrics, shortening their lead times, or meeting their commitments. They believe by visualizing and managing improvement work a bit more like standard work, then things will get better.

What nags me is the number of teams I’ve seen struggling with these problems and coming up with the same solution. I won’t say adding a new “Improvement” work type to a team’s kanban system is a bad idea, but it’s a very limited way of looking at team improvement. Managing improvement work on a kanban system is also questionable for teams that already have difficulty consistently delivering their everyday work.

Before teams try to get more efficient at using their kanban boards to manage their retrospective action items, they should consider if having retrospectives meetings and trying to manage improvement work on their kanban board is part of the problem.

Instead of trying to run better retrospectives or better manage improvement work, let’s take a different approach; creating team-level improvement without either retrospectives or kanban systems.

No Retrospectives

The Scrum guide tells teams to gather to inspect the individuals, interactions, processes, and definitions of done of their last sprint. But if we dismiss that instruction. What options might that offer us instead?

My recommendation to teams is to challenge the idea that the only way to improve things is to discuss problems in scheduled, large group facilitated meetings.

A truly agile team wouldn’t delay their releases because an Agile framework told them they should. They would release to customers frequently, realize value sooner, and get early feedback. So why, when team members discover a problem, would you wait until a retrospective meeting to do anything about it?

Don’t wait. See a problem, fix a problem.

Resolving problems as they’re discovered is an established idea. One practice pioneered by the Toyota Production System was the Andon Cord. The Andon Cord was a rope employees could pull to signal when there was a problem. Pulling the rope would pause production, and while paused, the team would work to bring things back to normal before resuming production. The Andon Cord promoted swarming and fixing problems in real time. That’s what I encourage my teams to do. Don’t wait. See a problem, fix a problem.

Always look for the next “doable” improvement.

Troy Magennis

You don’t have to stop doing your retrospectives, but based on my experience, not many teams would be upset by the idea. I often see retrospectives as notorious for getting team buy-in and engagement. In many teams I work with, people would prefer to spend their time working on user stories than giving up an hour or two of their time in a meeting their experience tells them won’t change anything.

No Kanban Required

I don’t want to suggest that teams shouldn’t ever manage their improvement work on their kanban board, but it’s the only approach I see teams take.

One alternative is to make your improvements so small that trying to manage them using a kanban system no longer makes sense. Drawing a parallel between improvement work and everyday work, the smaller the batch size, the better:

• Smaller improvements reduce risk
• Smaller improvements have a shorter cycle time and can be implemented more frequently
• Smaller improvements don’t require as much time commitment
• Smaller improvements provide faster feedback and benefits
• Smaller improvements require less management
• Smaller improvements create more momentum

I suggest even thinking about improvement work that makes it onto a kanban system as too large and too late. By the time improvement items get created and pulled into a kanban board, some of that work could have been done already.

By getting people to solve little problems, you change their awareness so they’re prepared to do different things for the big problems.

Dave Snowden

Even better than improvement work being efficiently visualized and managed in a kanban system would be for improvement to a daily, continuous practice. Make improvement a daily habit.

Improvement Practices

It’s not enough to say that continuous improvement should be a habit because improvements are only the outcomes of the process. Improvements start as countermeasures to problems, small experiments you try and check to see if they made things better. A practice of continuous improvement requires the ability to experiment.

Even more important than daily work is the improvement of daily work.

Mike Orzen

In the example of the Andon Cord, pulling the cord would pause production; that ability to pause the production of work and shift your focus to fixing issues is another capability required for continuous improvement. One word that describes the spare capacity needed to be able to put work down and shift focus to problem-solving is “Slack.”

If your team members identify the need to address a problem but don’t have the time or have too much work to do, it’s a signal there’s not enough slack in the system.

Continuous Improvement Culture

If we look even more broadly than the skills and practices of a continuous improvement habit, what has a bigger impact is the culture supporting it. What actions does your culture encourage your team members to take, and is it influencing people to take the kinds of actions you want?

In kaizen culture the workforce is empowered. Individuals feel free to take action; free to do the right thing. They spontaneously swarm on problems, discuss options, and implement fixes and improvements.

David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business

If standard work is valued and recognized more than improvement work, that’s what people will choose. If people need permission before putting down their regular work to fix a problem, that’s a barrier they’ll have to overcome.

Lastly, does the team have enough ownership regarding their system boundaries and the power to change the things slowing them down? If implementing improvements always requires collaborating across teams or extra approvals, you’re more likely to see local optimizations but fewer meaningful changes at the system level.

Conclusion

If you’re already tracking improvement work on your kanban system and holding regular retrospective meetings, by all means, keep doing those things.

Use these ideas to support and extend what you’re doing now, including:

• Shortening the time between discovering a problem and resolving it
• Reducing the demand on your team and giving them the slack time to swarm on problems
• Making improvement something that’s talked about and happens daily, not just in retrospectives
• Addressing what’s preventing improvement from happening rather than creating more work to manage
• Paying attention to the cultural and system boundaries that affect the improvements your team can make.

Use continuous improvement as a constraint to get people to engage with smaller problems than they’re used to. Instead of relying on a kanban system or holding formal retrospective meetings, promote the behaviours of discussing, swarming, collaborating spontaneously and solving problems in real time.