Robert Hoekman Jr has recently launched the kaizen manifesto to promote the practice of continuous incremental improvement in software development:

“Kaizen (改善, Japanese for “change for the better” or “improvement”, the English translation is “continuous improvement”, or “continual improvement.”) is an approach to productivity improvement originating in applications of the work of American experts such as Frederick Winslow Taylor, Frank Bunker Gilbreth, Walter Shewhart, W. Edwards Deming and of the War Department’s Training Within Industry program by Japanese manufacturers after World War II. The development of Kaizen went hand-in-hand with that of quality control circles, but it was not limited to quality assurance.” (Ref.)

The principles of the kaizen manifesto are:

1. Make continuous improvements in every aspect of the business.
2. Actively pursue a superior, complete customer experience.
3. Continually improve designs, code, and processes.
4. Strive to increase agility (binshou) while reducing costs.
5. Use the Deming Cycle to minimize disruption from change.
6. Prevent errors (poka-yoke), in software and in business.
7. Respect people, leverage expertise, and trust staff.
8. Reward suggestions, improvements, and progress.
9. Always move forward.

Part of the kaizen manifesto then is the promotion of Binshou or agility, however, Robert critique of kaizen via-á-vis agile software development appears, to me, to be somewhat misplaced. Specifically, the notion that kaizen isn’t a process rather a mindset whereas agile software development is a process with rigid tenets doesn’t fit with my interpretation of the agile manifesto.

For me both the kaizen and the agile manifestos promote an approach or philosophy to achieve better software – the difference is that the agile manifesto has since been codified into specific processes, such as Scrum or DSDM (in time so may the kaizen manifesto). To be fair, specific agile methodologies can (ironically) become rigid, religious, processes – or at least the way the methodologies are interpreted can, but that’s a criticism of the practitioners not agile per se.

What I find interesting are the synergies between the two manifestos, not the differences – what lessons can we learn from both manifestos to improve our software, professionalism and working practices. I propose the following:

• a focus on people and interactions, trusting the team and respecting their expertise to deliver the project;
• talk to each other and getting stuff done rather than writing comprehensive documentation;
• work with customers to create superior, complete user experiences;
• respond to change – learn what works, what doesn’t and improve designs, code and process;
• maintain momentum and keep moving – this means moving quickly and iterating rapidly.