An Introduction to Lean Thinking for Software

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:

Related Sponsored Content

• API Security for the Modern Enterprise

Related Sponsor

Protect Identities. Secure Digital Services. Enable scalable and secure user access to web and mobile applications. Start free trial.

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

• 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.

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

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.

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.

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.