Kaizen

Written on 12:13:00 PM by S. Potter

Kai-zen. What a fantastic word! A recent addition (ok, I am behind the times - more like 2 years ago) to English dictionaries is 'kaizen'. For years the Japanese have been using this wonderful word, which simply put means 'continuous and incremental improvement' or 'change for the better'. How wonderful to have one word to describe something that can be so layered in meaning? If you read the wikipedia entry you will find kaizen is about attaining the following goals:

  • eliminating waste*
  • just-in-time delivery
  • standardizing work
  • using only appropriate equipment
  • leveling load
  • plus others...
(* waste is defined as "activities that add cost but do not add value") In fact, kaizen is about taking a process, system, product or service apart and putting it back together again with the sole purpose of improving it. Kaizen is a whole philosophy that does not only encompass mechanical or purely business principles, but also humanizes processes and promotes respect for people. Without this basic respect honored there will be no continuous improvement at all. Taken directly from the wikipedia...
Importantly, kaizen must operate with three principles in place: process and results (not results-only); systemic thinking (i.e. big picture, not solely the narrow view); and non judgmental, non-blaming (because blaming is wasteful).
Hopefully now, you will understand why I fell in love with this word almost immediately. I am surprised that developers haven't started using this word, such as 'kaizen programming' or 'kaizen development'. I do think that Agile development methods and practices are moving very close to the essence of the meaning of kaizen. Perhaps now we should take these processes apart and reassemble with the purpose of improving them, ad infinitum. Unfortunately due to human error and nature we will never find the perfect methodology, but we can use common principles we all believe in to move us closer to our utopia, whatever our poison is (in my case software development). Taking a fresh look at CMM and Six Sigma, I wonder if this is where both processes originated from. If so, over the decades both have devolved and moved away from their founding principles. I am not attacking the CMM approach or Six Sigma methology at its roots, but pointing out that in industry today, their implementations (in my experience) have lacked any notion of humanizing the process. I have found the contrary true, they both try to dehumanize processes, which contradicts kaizen fundamentally. Today I decided to marry my former favorite word, mojo, with kaizen and registered kaizenmojo.com. Not completely sure what will be on this site, but I do have some software development productivity tools that need a home, so this might just be the perfect place. So continue improving...

If you enjoyed this post Subscribe to our feed

4 Comments

  1. Hollis Waite |

    Never heard of 'kaizen'. Guess I'm further behind the times than you. Nevertheless, the concept seems like a variation on something we've all advocated at one time or another. Think long term, work smarter not harder, refactor, etc. Funny that something that is seemingly so obvious ends up consistently getting the short shrift. We're a lazy species but I think it goes further than that. Every organization I've been a part of has done a poor job aligning the interests of the individual and those of the organization at large. When mistakes are punished much more harshly than successes are rewarded, why rock the boat? A rant for another time. What I'm curious about is why displaced individuals are considered the result of failed kaizen. Seems to me that improvements that are beneficial to all participants constitute only a small subset of refinements which would benefit the group as a whole. Almost all changes have both winners and losers, no?

     
  2. S. Potter |

    In reference to your first point, yes I think that is exactly why the concept of kaizen is so powerful to me, because it is so obvious but so hard for us humans to implement. In fact, looking at political movements such as Marxism that spurred on Russia's communist regime, you will find Marx promoting the same core values that kaizen is based on. His vision and Russia's implementation seem very different than the results kaizen promotes, but they were based on the same core values. The same for pure capitalism. Our implementation of capitalism is far from its pure origins and far, far from perfect, but the core values in my mind are exactly the same as what drove Marx to his vision.

    What else should we strive for? Nothing? Or should we iterate on our experiences attempting to improve on humanity's past failed ventures?

    As for your final point, I understand what you are trying to say, and I agree. In isolated situations there will always need to be losers (plus hopefully also winners). However, on the whole many large layoffs in western economies are more about people being misplaced in an organization or given the wrong responsibilities and/or accountabilities.

    A common organizational anti-pattern is when organizations hire too many people because they are not being realistic in their expectations. This eventually leads to mass lay-offs. Sometimes it is that organizations compensate executives far too much and their lower-level employees not enough to encourage the lower-level employees to improve. Other times it is due to mid-managers and executives not knowing how to fully improve revenues, cut expenses and thus increase overall profit.

    Another situation is that many companies I have worked at do not find the right fit for the employees that don't work out in their original position. They either keep them on in a role they are not suited for, or they fire them without trying to find out if they could be a good fit in another part of their organization.

    For example, when I managed a J2EE project at a hedge fund client of mine 3-4 years ago, I had inherited three developers, one very senior (technically very very good and business-wise excellent), another mid-level developer who was very dedicated and above average in his skill set. The third developer, who supposedly had the same experience as the mid-level developer, was just an awful developer.

    He severely lacked understanding of the business domain (and completely uninterested in learning). This led to major issues with very simple requirements not completed in the QA testing phase and once or twice (I have to take accountability for this, even if he was responsible in an individual level by his persistent coverups) these types of defects ventured into production.

    Not only did he not understand the business, he wrote poor quality code on a technical level. Again it was up to the rest of the team and our lone QA engineer resource to babysit him.

    After 3 months of giving him constructive feedback, giving him finance course notes to read and providing him with ways to improve his performance in his role I realized that he wasn't interested in changing, he just wanted money for as little as possible. One day when I was watching over his shoulder I realized what he would be great at: UNIX system administration! This was when I was about to make a case to fire him.

    I spoke to my manager and unfortunately due to the political nature of the project we wouldn't have been able to fire him without political repercussions and we would not be able to get a replacement developer nor would he have been able to transfer to SysAdmin team. In the end my manager felt like he was forced to make a terrible decision and kept the developer on the project.

    This developer is still on this, now, legacy system and will be until it is officially killed. The business users are frustrated with him, the QA team cannot talk to him at all (they yell), he ends up working much longer hours all because he is not right for the job and has to correct things other developers with his experience should not be making. Obviously the developer is making the organization waste money (even if they are saving money on using him because they aren't paying him very much). The issues his lack of skill and attitude have caused the organization are quite severe as people affected span many teams.

    I think that is what kaizen is trying to say...be proactive, anticipate and respect individuals involved in your organization and iterate to improve. Kaizen MUST apply not only to the organziational structures in our societies, but also to individuals. Such as the developer I wrote about above. Kaizen needs to be a two way process, not just the organization's responsibility.

     
  3. S. Potter |

    BTW I didn't mention Hollis that your points were very good. Sorry I got caught up in my thought there (again)!!!:)

    PS AJAX rules (j/k)!

     
  4. S. Potter |

    Today Kaizen was the Investopedia Term of the Day that I receive in email daily. Here is what they had to say:

    A philosophy that sees improvement in productivity as a gradual and methodical process. Kaizen is a Japanese term meaning "change for the better". The concept of Kaizen encompasses a wide range of ideas: it involves making the work environment more efficient and effective by creating a team atmosphere, improving everyday procedures, ensuring employee satisfaction and making a job more fulfilling, less tiring and safer.

    Some of the key objectives of the Kaizen philosophy include the elimination of waste, quality control, just-in-time delivery, standardized work and the use of efficient equipment.

    An example of the Kaizen philosophy in action is the Toyota production system, in which suggestions for improvement are encouraged and rewarded, and the production line is stopped when a malfunction occurs.

     

Post a Comment