An Introduction to Lean Thinking for Software

Posted by Jacky Li on Jun 23, 2008

Sections

Process & Practices,

Architecture & Design

Topics

Agile ,

Delivering Value ,

Methodologies

Tags

Continuous Improvement ,

Lean

For developers and leaders coming to Agile via Scrum or XP, all this talk about Lean may be a bit of a mystery. Here's an introduction to Lean Thinking and how it applies to software development, from the Agile Editor of InfoQ China, Jacky Li. Ning Lu of ThoughtWorks China, whose talk is summarized here, emphasised the biggest obstacle to Lean or Agile as: the mind-set which came into being during the period of large-scale production.

Earlier this year, InfoQ China held an Open Party together with Matrix, ThoughtWorks China, Beijing Java User Group, AgileChina Google Group and Beijing Python User Group, etc. The Open Party, running along the lines of an OpenSpace  unconference, took place at the ThoughtWorks China office, and there were about 30 people attended. Ning Lu, a consultant from ThoughtWorks, gave a nice speech: Lean Thinking With Examples. He analyzed the biggest obstacle in the way of adopting Lean or Agile, and described how to recognize and reduce waste. This article will summarize the talk from an agile developer's perspective.

The activity started with a simple stand-up meeting, followed by voting on all the topics - we had a lot of wonderful topics that day, including "The growing of open-source community", "GPE", "Mingle", "Erlang", etc. The topics were separated into 3 tracks, and Ning Lu gave his talk on one track. He started with the history of the Toyota Production System and Lean Manufacturing, then tackled the biggest obstacle on the way adopting Lean or Agile: the mind-set which came into being during the period of large-scale production. Ning Lu also talked about how Toyota explored its own production system. He said:

Lean is the technology that can recognize and eliminate waste - activities which don't produce additional value.

He explained how to recognize and eliminate waste with The 5 Lean Principles* with examples, and listed out several typical phenomena which always accompany waste:

• Inventory - while inventory can avoid inefficient provision, it also creases cost, and makes the company become insensitive to the market. The company might face overstocking as the market requirement changes. Inventory is everywhere. Think about your bookshelf, refrigerator, and work that terminates without any result.
• Batch processes and waiting in queues - such as the intersections that are always crowded, most of the drivers have to experience "waiting" there.
• Unbalance - e.g. seasonal sales and periods of slack sales.
• Complication - if things are much more complicated than you expected, then there must be some waste. For example: a complicated document or process.
• Focus on "following the regulations" - not all rules and regulations are reasonable, and even so, they might not be valuable to the clients.

Ning Lu emphasized that:

Any work that's not finished is a kind of waste. Lean or Agile can minimize unfinished work.

Heck, it sounds like all the code being written is also waste. That's crazy! If we follow the words above and try to minimize waste, then it seems that we should stop coding! How can we deliver something to the customer, then? And where does the value come from?

OK, let's try to look at it another way. Maybe you recognize these words from "Prefactoring":

Can you foresee everything? No. Are the decisions you make today final? No. It's practically impossible to think everything or know everything in the beginning of a project.

Actually, even the customer won't be sure that the function is exactly what they wanted, before it can be proved valuable to them. 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.

If we can buy this idea, then we will need to find a solution to eliminate waste, i.e. unfinished work. So what shall we do?

The 5 Lean Principles give us a clear, step-by-step direction, and when it comes to software development, there's a very useful toolkit composed of many agile practices which can help us resolve every concrete problem. To reduce the time between code completion and its being tested and integrated, we need to take small steps forward, doing frequent check-ins and continuous integration. To reduce the time between feature completion and and the time it starts creating value for customer, we need to do frequent delivery. As we can see, Lean and Agile development are integrated perfectly at this point!

Four months ago, Amr Elssamadisy suggested on the news, "Opinion: Refactoring is a Necessary Waste”:

...there are two types of waste in Lean: pure waste, and necessary waste. Pure waste is one that has no value to either the team building the software or the customer using the software.  Necessary waste, on the other hand, is the best way we currently know how to do a job even if it does not have customer value.

Ning Lu also talked about the kinds of waste defined in Lean, especially the second type, called "necessary waste". In his opinion, test, integration, refactoring and management all belong to this kind of waste. He summarized several interesting patterns that are commonly used to reduce those forms of waste:

• Treat it positively: reduce the number of team members and beef up recruitment requirements
• Change personal tasks to "team tasks": the whole team together takes on the work of design, test, and part of integration. The team is self-organized. Code ownership is shared within the team.
• Separate responsibilities between people and machines: make every possible kind of work automated.
• Do work ahead of time, and frequently: introduce test driven development, do frequent unit tests, refactoring and integration in early stages. Make sure that everyone can have a clear understanding of project goals early on, and ensure that project status is always visible.

For those interested in reading more on this topic, Mary and Tom Poppendieck's website offers articles. Also, Jeff Xiong and Ye Zheng, consultants from ThoughtWorks China, have written useful articles about the relationship between Lean, Agile and waste: Agile - Eliminating Waste (in Chinese). The slides from this talk, also in Chinese, can be downloaded.

View the original Chinese InfoQ item here: 路宁谈精益思想——2008北京Open Party摘录, and the story of this event, with some videos.
 

---

---

About the author

Jacky Li is the Lead Editor of InfoQ China/Agile Community, specializing in Java and Agile software development, and has been devoted to popularizing Agile in China. He is now working in Ethos Technologies as Tech Leader, and has translated the Chinese editions of the InfoQ minibooks: Starting Struts2 and Scrum and XP from the Trenches from English.

1. Back to top

   good article,

   by Muhammad Faizan Ali

   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.

   Reply

2. Back to top

   Great article!

   by Daniel Wildt

   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.

   Reply

3. Back to top

   Re: good article,

   by Li Jacky

   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.

   Reply

4. Back to top

   Re: Great article!

   by Li Jacky

   
   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!
   

   
   
   Yep! Implementing Agile(or Lean) is a long turn process, and it would be even more difficult if one only try the practices without understanding the philosophy.

   Reply

5. Back to top

   Good Job

   by mnoman khan

   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

   Reply

6. Back to top

   Be Careful

   by Irakli Nadareishvili

   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.

   Reply

7. Back to top

   Re: Be Careful

   by Jim Leonardo

   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.

   Reply

• Older >