An Introduction to Lean Thinking

well, it is true that it is impossible to foresee everything. in the beginning ever, the requirments are not clear, we can't say any work a wast unless , that work has not been passed through certail developement process. so i don't agree that wo should stop coding. infact our work is currently going through development process, not complete yet.

Regards.

Jacky, great article about Lean Thinking!



The way I see, before learning Scrum, XP or any flavor of Agile, people should understand about Lean Thinking and its principles.



It's all about the cultural change!

But... how?



Reading is good, but not enough.

We need to practice and learn. Improve, learn, adapt (remove waste), and try again.



About reading, one could start with a Mary Poppendieck's book, let's say "Lean Software Development - From Concept to Cash". Also reading something related to Toyota (i.e. Taiichi Ohno or Shigeo Shingo) is important.

Eh....actually, I didn't mean that we should stop coding.
I just want to say that

If we take unfinished work as a form of waste, then we will be dedicated to turning the code into running software, and deploy it into a production environment a.s.a.p. Later we will get feedback and more detailed requirements from the customer, and we can find out whether the committed functionality is finished (or not). The more unfinished work we have, the bigger the risk will be.

The way I see, before learning Scrum, XP or any flavor of Agile, people should understand about Lean Thinking and its principles.

It's all about the cultural change!

You took the WIN




Last sunday ,22 jun 2008,I read an about porche ,toyota and toyoda .How they introduced and implemented the lean management and what is really lean management is. I was thinking how can we put them in software engineering and can't find a clue to implement, you did a great job and make my thoughts clear and stream line.Thanks a lot.Good Job.




Regards


Noman Khan

Be careful when you try to copy/paste a manufacturing process into the software realm. For somebody who is familiar with LEAN in manufacturing, a whole bunch of things worried me when reading this article.


First of all, LEAN is a Just-In-Time process and the main principle of LEAN is that the production of any unit of work is triggered by actual demand. That is not the same as "push code into production asap and then get feedback" described in the article. You could even say - it's the opposite.


Another important issue with lean is quoted on Wikipedia: "A lean process requires reduced variability and uncertainty in the supply chain to reduce needs for raw materials and finished goods inventories." Manufacturing companies use rigorous forecasting to achieve reduced variability. In software engineering, as we all know, variability, ambiguous requirements and changing requirements are the fact of everyday life, so there is a big question whether LEAN is applicable to software engineering, just because it was successful in manufacturing.


Another interesting quote from Wikipedia: "LEAN has recently been introduced into Her Majesty's Revenue and Customs in an attempt to improve customer service within the government department[citation needed]. This however, has not been a success. Productivity in LEAN areas is down and staff morale has hit an all time low. This can be put down to a few factors, mainly mis management and the LEAN process not being fit for purpose in a UK office environment."


All that said, it's good to see that people are trying and looking for ways to further improve processes.

I'd also add to the be careful list...(applies to anything Agile too)

Find out what it means, not just use the word. Lean != Lightweight.

Like we're accustomed to in anything Agile, Lean at its core is about trimming out unneccessary/unproductive bits and minimizing overhead bits so you can focus on those things that provide value. I would say Lean mfg can teach us some things, but I'd also agree that it's not an easy map between the two. I think we should be looking at the principles, but not necessarily the actual approaches. At the end, I(at the risk of sounding ignorant of Lean) see very little difference between the driving principles of Lean in manufacturing and the Agile Manifesto that can't be explained by the differences in product.