'Kaizen' Versus Discontinuous Innovation

Comments

# mep50 said on March 2, 2006 4:03 PM:

Interesting blog; I am very familiar with Kaizen having worked in the semiconductor industry for years but have never heard of discontinuous innovation sounds like a fancy term for invention.

I don’t think you can say Kaizen vs. Discontinuous Innovation because you cannot have one without the other.  First something is invented and then in order for it to last continuous improvement needs to occur with the users.  This almost always is in the form of quality improvements to the original invention.  So you need the idea first then implement and improve on it.


Interesting though, the United States was the first to come up with the (Discontinuous Innovation) of continuous improvement long before the Japanese culture.  U.S. manufacturing did not embrace the concept and take it seriously but Japan implemented it brilliantly which is why as you listed they are the biggest car company in the world.  It comes down to quality.

Now if we could just model it in the same way for the software industry regarding quality. ^_^

Mark

# Ivan Joseph said on March 2, 2006 5:41 PM:

Interesting thoughts mep50.

I'm sure we've become better and better at continuous improvement since we've now been doing it for so long. So there is a gold standard of 'learning by doing' which could be part of Microsoft and needs to be institutionalized. Other s/w companies also must have developed a 'Kaizen' like approach- anything else would be wasteful.

You could say discontinuous innovation is in fact invention - the electric bulb, steam engine etc being classic examples. Is Post-It an invention - I guess it is and wouldn't one  categorize the Walkman too as an invention?  The reason they are discontinuous is that on the product development curve this wasn't treated as another step in the continuum of incremental product improvement. It came out of nowhere - in other words it created a new curve and in that sense was discontinuous.

Does that make sense?  

# mep50 said on March 2, 2006 7:47 PM:

Yes that makes sense.

I agree the U.S. has gotten better, kind of late in the game though not until the late 80’s.  I remember in the early 80’s my parents had a Pontiac Phoenix I think was the model name and sometimes when you honked the horn the windshield wipers would work.  We have come a long way since then for sure.

Software seems different though especially by industry or engineering disciplines.  For instance in a software engineering class that I took it was brought up that software can be made to have very high quality built in.  The reason that software struggles in this area is that for the most part there is no liability associated with the software if it breaks so the need is not there.

So say an air traffic control system or the brake system in your car the software is very robust and redundant etc.  Software in the gaming industry does not necessarily follow this convention.  I think having processes and standards is part of the issue as well.  If we could somehow take what we can do in say auto manufacturing and model this in software manufacturing.  

So why do you think quality is so esoteric regarding software?

# Ivan Joseph said on March 3, 2006 4:49 PM:

Is the software quality esoteric? I'm not sure. Is it variable? I think the answer is yes.

This has IMHO got something to do with the following:
1. Writing code has some degree of creativity to it. Not all programmers are the same and they approach the process of writing code differently.

2.Since this industry has grown very rapidly, not enough time has been devoted to process improvement- once you've shipped it's on to the next big thing.
3.Shipping as the primary goal: Most product teams are focused on shipping the product (and with very good reasons) and breathe a collective sigh of relief once shipping is done. Often they also re-org and join other teams. The unintended consequence of this is that if what has been shipped is not perfect/ is broken the people who've built it might have moved on and so they aren't held accountable.
4. Too many features, unclear business value: Often the product/ features are built and then we try to develop a value proposition instead of starting first and foremost with designing the value proposition. So there could be a disconnect b/w what is built and what is required. We just have to look at the no of features that are part of any major s/w product and ask the question about business value of each of these features. Did the Product Planners analyze these features for business impact before handing over to Engineering? Was Product Planning involved at all? Is there a Product Planning function prevalent across all s/w companies/ all divisions within a company?

I know that a lot of great work is being done in Microsoft to align the Engineering and Marketing disciplines and by all accounts significant progress is being made. But there is scope for improvement and here 'Kaizen' is particularly useful.

Perhaps we should 'Kaizen'ise s/w development:-)