Is Kaizen Agile? (The Agilist’s Guide to Kaizen)

Kaizen is a practice that comes from lean manufacturing. And it translates to continuous improvement in agile. Here’s how to use it.

Published

I recently spoke with a friend of mine about the practice of kaizen in lean manufacturing—and how it relates to continuous improvement in agile. So she asked me one of those really good (and just as hard to answer) questions I get every so often: “Is kaizen agile?”

So here comes my latest blog post in my “Agile Conundrums” series, where I try to answer some of the trickiest questions about agile I come across. If you’re curious to know about kaizen and how it relates to continuous improvement, keep on reading.

So, is kaizen agile?

Kaizen is a practice for continuous improvement that comes from lean manufacturing. Organizations that practice kaizen encourage employees of all levels to make small improvements to their processes and tools every day—which leads to marginal productivity gains over time. Kaizen is the practice that gave birth to the idea of “continuous improvement” in agile.

Kaizen is a Japanese term which means “change for the better.” It’s a combination of the words “kai” for change and “zen” for good.

The term “kaizen” was coined by Tokio-born organizational theorist Masaaki Imai, known for his work on quality management, in his 1970 book, Kaizen (Ky’zen), the Key to Japan’s Competitive Success.

In 1986, Imai founded the Kaizen Institute Consulting Group (KICG) to introduce kaizen to Western businesses in Europe and the Americas.

“Kaizen is the single most important concept in Japanese management—the key to Japanese competitive success,” Imai writes in his book.

“Kaizen means ongoing improvement involving everyone; top management, managers, and workers. Kaizen is everybody’s business.”

Maasaki Imai

In its simplest form, kaizen is a lean practice for continuous improvement. It comes from lean manufacturing and was first used by Toyota as part of its management system, the Toyota Production System (TPS).

Today and thanks to Masaaki Imai’s work to spread the word about kaizen in the West, kaizen is practiced not only by Toyota, but by many American and European companies like Ford, Nestlé, and Lockheed Martin—and even in non-profit organizations like the Mayo Clinic.

Nissan Chemical Corporation, a subsidiary of Nissan that produces colloidal silica and colloidal electro-conductive oxide solutions for the international market, is one of the most popular examples of the benefits of applying kaizen. In 1977, the chemical producer was faced with declining profits—so its management team decided to tap into the know-how of its workforce to make its production plants more efficient.

Nissan Chemical Corporation implemented a company-wide kaizen campaign. The campaign asked workers of all levels to provide ideas for improvements to their workplaces, processes, tools, and systems which would help make the production processes of the company more efficient.

Between 1978 and 1980, the campaign had an ROI of 500% as $640,000 worth of improvements brought in $2.5 million (1980 USD) cost savings. Adjusted for inflation, that’s an investment of $2.5 million (USD) that brought in $10 million (USD) of returns.

Organizations that practice kaizen encourage employees of all levels to participate in the continuous improvement process by resolving ad-hoc issues as they emerge and collaborating with everyone else to identify and solve systemic problems.

How Kaizen Works

The theory behind kaizen is simple but powerful:

When every employee of the organization thinks and acts like an owner—making small changes to the processes and tools every day—this leads to marginal gains in effectiveness (doing the right things) and efficiency (doing the things right) for the organization. Kaizen promotes ownership and continuous improvement by allowing staff to surface and solve issues.

We’re often tempted to think that big changes made abruptly will lead to better outcomes than small changes applied continuously. This is especially true in Western society, like the U.S., Canada, and most European countries, where governments change, organizations reorganize, and staff churns every few years.

Kaizen advocates for gradual and ongoing change; the type that’s more common in Eastern society, especially in Japan, South Korea, and China. To the naked eye, a Japanese production plant will look the same for years. Yet not a day goes by without someone making some kind of improvement somewhere in the organization.

According to kaizen, everyone in the organization—from entry-level workers to senior-level management—is responsible for two things: improvement and maintenance. By maintenance, kaizen means maintaining high standards through staying disciplined and sharing knowledge. By improvement, kaizen theory refers to raising the bar higher.

In a kaizen organization, anyone is empowered to make improvements to the processes and tools. Once improvements are made, everyone is responsible to maintain them. This is why organizations, teams, and individuals that practice kaizen are so effective and efficient at whatever they do. And the longer they do it, the better they become at doing it.

Point Kaizen vs. System Kaizen

In general, there are two types of kaizen: point kaizen and system kaizen.

Point kaizen is about fixing things when they break. In a way, point kaizen is an emergent and reactive type of continuous improvement. In an agile software development setting, point kaizen can mean fixing a bug or making a small tweak to the CI/CD pipeline that automates an otherwise manual step.

System kaizen is about fixing systemic problems. System kaizen is an intentional and proactive type of continuous improvement. An example of system kaizen is the retrospective in Scrum and Extreme Programming (XP), which we’ll cover in more detail in a minute or so.

For an organization to benefit from continuous improvement in the long term, it needs to practice both point kaizen and system kaizen. The former helps the organization resolve minor issues as they emerge, the latter enables it to address major challenges as they are identified.

In kaizen, everyone should seek out small improvements closest to their line of work and personal responsibilities. This is why in lean manufacturing organizations, workers are encouraged to think mostly about point kaizen and management is encouraged to think mostly about system kaizen.

How to Practice Kaizen in Agile Projects

If you work in an agile organization or team, you’re already practicing kaizen through the agile practice of continuous improvement. The most common example of continuous improvement is the Sprint Retrospective in Scrum.

The Sprint Retrospective in Scrum

In Scrum, teams that consist of 3 to 9 members build products or solve problems in an iterative and incremental way. Iterative because they work in short cycles called “sprints,” usually one to four weeks long. Incremental because they ship in small chunks called “increments” at least once per iteration.

As with most agile frameworks, Scrum prescribes a set of roles, events, and artifacts that help the team to work in an agile way. A key element of Scrum is the Sprint Retrospective, a meeting between 60 to 90 minutes at the end of each sprint where the Scrum Team gets together and asks themselves:

  • What went well?
  • What didn’t go well?
  • What problems did we encounter?
  • Which of these problems did (and didn’t) we solve?

The Sprint Retrospective is an agile practice that allows the Scrum Team to achieve continuous improvement (and therefore practice kaizen). The Scrum Team’s members focus on what happened in the sprint—and identifies the small changes that they can make during the next sprint.

Since most sprints last 2 weeks, this means that the team’s timespan when thinking about continuous improvements in the past 2 weeks for the as-is state and the next 2 weeks for the to-be state. Over time, they achieve marginal gains as these small changes and minor improvements add up, taking their communication and collaboration to the next level.

The Sprint Retrospective in Scrum is one way to turn continuous improvement into a habit for everyone participating in the Scrum Team.

Scrum is simply one of the agile frameworks out there. Extreme Programming (XP), a software development framework co-created by one of the signers of the agile manifesto, also encourages its practitioners to do kaizen through its so-called “simple rules.”

Collective Ownership and Fixing It When It Breaks in XP

Extreme Programming (XP) has a set of simple rules that practitioners of the software development framework should follow.

Two of the framework’s simple rules, “collective ownership” and “fix the process when it breaks,” are yet another way for an agile team to practice kaizen in software development projects.

Collective ownership in XP means that all the members of a project team are encouraged to contribute new ideas to all areas. The collective ownership rule is very similar to the kaizen practice, which encourages employees across the organizational hierarchy to think about ideas for improvements. Similarly, individual developers can add or change lines of code, fix bugs, or improve the system’s overall design.

The second rule of XP is to fix the process when it breaks. This doesn’t mean that the members of the project team are encouraged to do whatever they want; it means that each of them owns the functioning of their process and tools. Making informed tweaks to them when they’re not really working for the specific case of their project, then, is encouraged.

Continuous Improvement from the Agile Manifesto

Agile is, to a large extent, grounded in the management theory and best practices that come from the lean manufacturing and product development movements in Japanese and American companies (like 3M, HP, Honda, Canon, and others) of the 20th century.

Agile is a mindset powered by four values and 12 principles, which lays the ground for an unlimited number of individual practices and the frameworks that package them for repeatable and scalable use.

Two of the 12 principles in the Manifesto for Agile Software Development (agilemanifesto.org) are closely related to kaizen:

  • Principle #9. Continuous attention to technical excellence and good design enhances agility.
  • Principle #12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is why kaizen (and continuous improvement) is at the heart of agile. In an agile team, everyone owns the ways of working. Every member of the team is encouraged and expected to contribute with ideas and improvements, through the day-to-day work and through their participation and commitment in events like the retrospective in Scrum and XP.

Ironically, this is also what many agile teams often get wrong about continuous improvement. It’s not about grand changes and big sways. It’s about the small changes and minor enhancements that, over the course of time, lead to marginal effectiveness and efficiency gains for the team.

One area that agile teams get wrong about kaizen is that it’s a combination of improvement and maintenance. And while small and ongoing improvements are key, the discipline to maintain process discipline and knowledge sharing is just as essential to working in an agile way.

9 Ways to Implement Kaizen in Agile Projects

By now, you know what kaizen stands for and how it relates to the agile practice of continuous improvement.

Here are 9 actionable ways that you can use today to implement kaizen in an agile project:

  1. Use common sense and measurement to identify areas of ineffectiveness (not doing the right things) and inefficiency (not doing the things right).
  2. Take ownership of your process and tools. Promote the owner’s mentality to everyone else whom you’re working with.
  3. Look for areas of improvement within your work area, your geographical unit or business function, and your organization.
  4. Practice this mindset any time, with a preference for recurring events that create cadence/cyclicity like the retrospective.
  5. Focus on simple changes that are inexpensive to implement and that leverage existing technologies.
  6. Each change should result in a measurable on-the-spot improvement, revision to work procedures, processes, and policies, or revision to organizational systems.
  7. Focus on people, process, and technology to practice kaizen holistically. In the long term, kaizen should result in greater ownership and boosted morale.
  8. Simplify. Automate. Streamline. Visualize. Seek to introduce openness and transparency.
  9. Make gradual and visible improvements. Aim for what can be measured, qualitatively and/or quantitatively.

The Bottom Line

Kaizen is a lean practice, not an agile one. It comes from the Toyota Production System (TPS) and the lean manufacturing movement of the 20th century.

Agile is, to a large extent, best on best practices from lean manufacturing and product development that leading companies like 3M, HP, Honda, and Canon used to stay ahead of their competition in the 1980s.

This is why kaizen translates to the “continuous improvement” practice in agile. Just like a shop floor team seeks to continually improve its processes and tools, bringing in efficiency and eliminating waste, an agile team constantly looks for opportunities to improve their ways of working, internally and with the customer.

Categorized as Lean

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.