Kaizen and Scrum

Kaizen, the process of "improvement" in the Toyota Production System, is a valuable complement to Scrum, based on many of the same principles. It means teams can get effective results both from their retrospectives and daily attempts to resolve waste.

At the core is a variant of the PDCA loop with one extra stage: Observe, Plan, Do, Check, Act:

• Observe: identify wasteful activity and things which need to be improved. "Go and see" - look at the causes of why the waste occurs.
• Plan: create a plan to address the waste. Involve everybody who could make a positive impact, even managers: "Kaizen is everybody's business"
• Do: carry out the plan.
• Check: is the plan improving things? Should the team adopt it as their standard, or try a new idea?
• Act: adopt effective plans or discuss why an ineffective plan failed. Return to the start of the loop.

The key to getting in the Kaizen mindset is that these observations and plans don't have to be big, sweeping strategies or bold new directions. Effective Kaizen is about continuously finding achievable improvements that you can make as a team. "Assembling for our stand-up is slow because we lose track of time - let's put an alarm clock in our work area and see if that helps" is an example of a Kaizen. Maybe it works, maybe the team find it patronising and annoying so decide to try something else. Observe, plan, do, check, act.

Sprint Kaizen

An easy way to integrate this into your scrums is to run it at the same frequency as the sprint cycle, with the retrospective acting as the hub for the Act, Observe and Plan stages. It's easy for teams to pick up as it's not a huge step on from what they're already doing in the retrospective - good teams often end up settling on an informal version of this process without identifying it specifically as Kaizen.

The important part is the "do", "check" and "act" stages of the loop. Almost anybody can observe things in need of improvement. It's a lax scrum master who doesn't then push the team into the "whatcha gonna do about it?" discussion and come up with a plan; otherwise what you've got is less a retrospective than a cathartic moaning session. The challenge teams face is usually in carrying out their plan, measuring its effectiveness and deciding where to go next. Without formalising these steps, you can end up with a series of retrospectives that always identify the same problems and always come up with the same plans to deal with them, without anything ever happening.

Daily Kaizen

Another option for teams who are a bit more comfortable deviating from the textbook Scrum approach is to replace the daily standup with a daily Kaizen meeting. This can be beneficial when you have a focused team who communicate well and no longer need the standup as a means to tell each other what's going on. It can also work for teams who tend to over-focus on what they got done rather than what needs doing and what's in the way.

In this format, the team starts by asking itself two questions,

• "What is wasteful and slowing us down?"
• "How can we try to fix it today?"

Then towards the end of the day (or at the start of the next day's daily Kaizen meeting) the team should gather again and ask:

• "Did our plan improve things?"
• "Should we adopt it?"

In this way the team can roll over the small imperfections day by day, leaving their retrospectives free to concentrate on the bigger problems.

Continuous Kaizen

Having a regular Kaizen meeting is a good way to make sure things are always improving in some small way, but a team that's experienced with the process will want to go further than that. This means starting a Kaizen the moment waste is identified. It needs a bit of experience with the process, as teams who aren't used to how it works and what's achievable will struggle to get the balance right. Either they'll spend the entire day downing tools to start a Kaizen because the kettle needed filling or there's an ant in somebody's lunchbox, or they'll never start one even though the build server's on fire and the network keeps dropping out.

Once they can navigate that fine line of when starting a Kaizen is productive, though, being ready to call one at any point can really accelerate the process of improvement. The aim is to correct inefficiency and waste the moment it's spotted. You might need some tweaking to avoid overcommitment (a Kanban for tracking, or at least a team code of conduct to never have more than two Kaizens in flight at the same time) and distraction from the main task of getting work done, but done well it means you have a team who immediately huddle to solve waste rather than carrying a large variety of minor irritations into their retrospective or stand-up.

The key to all of these variants is that you're always looking for some way to improve things and measuring its effectiveness. Some teams do this anyway, but if you find you're saving everything up for a group moaning session at the retrospective and never doing anything much about it then adding Kaizen into your scrums will be a big help.