Womack Speaks about Lean (Video)

[Daryl Kulak]

Hi,

James Womack, the person who coined "Lean" speaks briefly about his thoughts on how Indian companies have adopted his work.

[Geri Winters]

In your email, you mention the shortsightedness of Mr. Womack's views. I'd like to know your viewpoint on that.

What I heard in this video is that a company should focus on the customer, and the company processes are about serving the customer efficiently. While it is true that there is other work in a company (Operations do not directly support the customer, but the company), I think in many companies the LACK of focus on the customer is leading to a LACK of focus on the purpose of the company and leading to gross inefficiencies in the running of the company.

I'd like to hear your thoughts on this.

Geri

[Daryl Kulak]

Yes, focusing on the customer is good stuff. Here is what I heard in the video.

Services companies are exactly like manufacturing. This is where software goes so wrong so many times. We try to treat our software teams like they are producing "widgets" and can pump them out regularly like car parts. So we think "Okay, user stories are our car parts, so let's make them all the same size and then start churning." This is a big mistake. Software development bears more resemblance to designing a car than manufacturing it. But to Womack, it must be treated the same, because otherwise the Lean stuff could not be applied to services, in his mind.

Serving the customer is not new to Lean. Business Process Re-engineering (BPR) had this same focus, and actually failed in a very similar way to how Lean will fail. BPR tried to ignore the fact that we have people in our processes, that we can shuffle people around with no consequences, we can treat people like machines. Didn't work for BPR and Lean is headed in that same direction.

[Jim Miller]

Have you read anything on the Toyota Product Development system. I've read quite a bit about Lean Product development recently, and it is dramatically more applicable to software development than lean manufacturing. For example, lean manufacturing strives to reduce variability, whereas lean product development strives to encourage variability early and often in the process, to cast a wide net with respect to options.

Here's an interesting article on how western financial thinking is a root cause of thinking lean will solve serious fundamental problems:

http://www.sme.org/cgi-bin/find-articles.pl?&ME06ART83&ME&a...

I couldn't agree more, consider the process of annual budgeting and the incredible amount of expectation inventory that it creates across the organization. Its impossible to list all of the downstream inefficiencies that this bloated inventory creates. Furthermore, it prevents what ultimately needs to occur which is the continual interaction of the independent groups required to deliver real it-enabled value. I will now descend from my soap-box...

[Daryl Kulak]

Wow, that's really interesting. I was not aware of Toyota's Product Development process. I'll have to learn more about that. Sounds like Toyota doesn't try to cram their own manufacturing process into a place where it doesn't belong. As far as I know, Toyota does not use the Toyota Production System in their IT group. Do you know?

[Jim Miller]

yeah, the Toyota product development system is actually very different than their manufacturing system. For example, cast a wide net and encourage variability in product development, stamp out variability in manufacturing. Most of the fundamental principles are the same, but they are implemented in a very different way, much closer to how you would think software development would work. I don't really know anything about their IT organization, its hard for me to imagine that many outsiders have drawn the comparison and they haven't though. The metaphor i like is that, in software development, we create little factories or assembly lines, for transactions to go through. So essentially their cars are our transactions, not a perfect comparison, but fairly decent... Looking at the lean product development specific principles, its very easy to see how they are fundamentally a much more organic system of development.

[Geri Winters]

Great article. Thanks for the link. Very thought provoking.

Many years ago, companies focused on long-term goals. The 3-year plan, the 5-year plan, the 10-year plan. In recent years, it seems so many companies are focused on the quarterly goal, and it always seems to be financial. I think this really feeds into what the article is discussing about financial controls driving a business. I have seen so many really bad things come out of this approach! Maybe Toyota's successes will open some eyes that there is a better way to run a company.

[Geri Winters]

I couldn't agree more - software development is NOT a manufacturing process, and until we get away from that thinking, we'll continue to have problems. If you are doing a pure bug fix kind of project, MAYBE you can get away with the idea of pumping out code like you create car parts. Or maybe if this is the umpteenth time you have built the same kind of system you can treat the project like a manufacturing process (maybe someone has gone from one company to another building the same code every time). Otherwise, there is too much variability. The only part of software development that is like manufacturing is stamping out the CD's to package up for sale after the project is over.

Another thing I agree with - you can't shuffle people around like machines. I have become convinced over the years that a large percentage of the failure of software projects comes down to people issues (rather than process or technology). I get so tired of having people referred to as "resources". People are a lot more complex than that! One Java developer is not the same as another.

OK, off my soapbox ;-)

[Jim Miller]

Its interesting that you bring up defect fixes, in large enterprises that really seems to be the only place that kanban and pull work relatively well. In most of the environments I've seen, agile teams simply do not control or have enough insight into the value stream to really use pull effectively. You have to really get out ahead of your dependencies which is going to force much more of a push model. But for defects, it seems to really work well. That is if you want to separate dev and defect teams...