Lean is more than a set of tools

August 31, 2009 — Posted by Al Shalloway

I hear a lot of people talking about Lean as if it were just a set of tools.  I also hear a lot of people saying it doesn't make any sense to try to contrast Scrum and Lean.   If you believe the first, you will likely believe the second. This blog is an attempt to show how Lean has a set of tools, but isn't just a set of tools.  By tools, in our case, I mean the practices with which to solve problems we encounter.

Before I talk about Lean, however, let me talk about real tools - since that is the analogy I am most often given.  Let's say you are a carpenter and have a tool box.  It doesn't make sense to talk about one tool being better than another.  The question is, which tool works best in this situation.  As a carpenter, I can learn how to use the tools in different situations.  Let's say I mostly make furniture.  Then I can learn how to build dressers, how to build cabinets, how to build tables, ...  I can learn which tools to use in which certain situations.  There are quite a few number of these, but I can become fairly proficient at it in my domain. 

What, however, happens if I become a journeyman? Now, I am in a new situation.  I have experience using tools, however, so I am not lost.  I try the tools in the new situations.  I see what I did, contrast it to what I wanted, and adjust my methods accordingly. This is the "inspect and adapt" approach many agilists are so fond of.  There is some waste in the process, but results will eventually be achieved.

Now, what happens if one knows more than how the tools work, but also understands why they work.  For example, a basic carpenter knows that nails work in certain situations better than screws.  However, many carpenters don't actually know the mechanical laws on which nails hold together two boards vs the mechanics of how screws do it.   While it might be generally true that screws will provide more strength at a higher cost of implementation - it is only generally true.  Bigger nails in some situations will work better than small screws.  But too big of a nail and you might split the wood.   A carpenter will learn from experience what to use.  And in a new situation will make mistakes and correct. But if he knew the principles behind the mechanics of screws and nails, he might be able to make better decisions, more quickly, in a new situation.

In the physical world, this extra knowledge is often held in the role of an architect.  Someone who understands the forces of construction better and will figure out what is needed - letting those more proficient in practices, but less proficient in principles do the work.  In my mind this illuminates the distinction between knowledge that assists operations (practices the carpenter uses) and knowledge that assists decisions (principles being used by the architect).

This, of course, requires the belief that there is a set of laws here.  This is one of the fundamental differences in different "camps", so to speak, in the Agile community.  Many agilists don't believe there is such a set, and that what we do is more art than science.  We are in an empirical situation, to them, and we can only inspect and adapt our way through it.  On the other hand, many other agilists do believe there is such a set.  In my mind, this is one of the foundational beliefs of Lean-thinking - that there is a set of rules out there.  Plan-Do-Check-Act is based on the notion that we can plan our work based on our current understanding of how things work.  We check our results against this plan.  Part of our acting is then to redefine our understanding of the way things work.

So Lean provides practices to our Agile toolbox. Things like limit work-in-process (WIP) to capacity, don't do things until they are ready to be used (Just-In-Time), do value stream mapping, ...  This is the Lean toolset.  If one believes Lean is just this set, then picking the right tools to use is the best approach you can do.  Use Scrum practices (daily standups, sprint planning, ...) where they apply and use Lean practices when they apply.

If you understand the Lean principles underneath the Lean practices, however, much more is available to you.  First of all, all practices in software development are most likely better understood with the Lean principles. Using Lean principles, one can see how to better apply Scrum practices.  So Lean becomes a combination of Lean practices, which apply only within certain contexts, and the principles on which they are based - which can provide insights into any practice in any context.

Unfortunately, this approach does not match most people's learning or working style.  People like concrete practices to use.  One of the value of coaches is that they can relate to people in very concrete terms.  Very experienced coaches may not understand the principles on which their work is accomplished, but they have so much experience they can intuit good results.  People working with them will become more proficient.  At this level, both coach and disciple will view what is happening as following practices within particular contexts.

My view is that Lean is several layers deep.  The most visible layer is its set of practices:

  • limit work to capacity
  • use value stream mapping
  • have the people close to the work make the decisions on how to do the work
  • avoid large batches
  • continuously re-plan
  • avoid delays when possible
  • focus on getting value delivered to customers quickly more than focusing on having people always be productive

and there are many more.  But this is not Lean. This is merely a set of practices based on Lean-Thinking - or Lean Science as I sometimes call it.

Some of the Lean principles on which these practices are based are:

  • delays between when an error occurs and when it is detected causes waste
  • removing such delays can both achieve higher quality and lower cost
  • quick feedback results in lower waste
  • deferring commitments can reduce waste
  • optimizing a segment of the value stream often results in increasing costs, increasing time to delivery and lowering quality

and again, this is only a partial list.

The opportunity is for people to use Lean practices while getting deeper insights into Lean principles.  This will allow them to adjust their practices when they find themselves in different situations than they have found themselves previously.  In the world of software development, we are all journeymen.  That is, we are always working on new things than the things we worked on before.  Experience is invaluable here.  But an understanding of why we have achieved the results we have can be just as valuable.

If one is interested in learning more about these concepts, I highly recommend looking at our upcoming book Lean-Agile Software Development: Achieving Enterprise Agility.  Several chapters are currently online.

Alan Shalloway

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Please take a look the books "The Elegant Solution: Toyota's Formula for Mastering Innovation", "The Toyota Way", "The Toyota Way Fieldbook" and you will find out that the Lean development is process of finding decisions "In Box" with the available resources and capabilities. The Lean development is relying on 5 Why approach, Genchi Genbutsu and so on.


There is no expert who can make me thinking if I don't want!


I thoroughly support the identification of Lean principles... in fact any principles that can help provide a foundation for project control. The principles then need support by the day-to-day activities of the selected methodology. My point here is that the methodology has to be selected. It is not a case of a single solution... certain projects and types of project do not require an iterative approach (although, IMHO, most do). Others absolutely must. The core principles can be supported in many different ways, depending on the project. What we do, generally, is not an art. If it is an art, then we are tending towards a research project rather than a production project. This brings its own set of risks, not the least of which is an undeveloped business plan.
The analogy with the carpenter is attractive, but it really fails to describe our industry. Carpentry is a craft business. A successful carpenter (by some measures at least) could be IKEA and their methods are as lean as you like. Once you start regarding what you do as unique, undefined and so on, you remove all possibility of developing efficient products. Each one is truly and unnecessarily unique. So, for all of our projects, we do need to identify principles; then we should discuss how to apply them to our particular project; then we run the project. The discussion would really not amount to much more than selecting one from several standard types of project. For commonality sake, whatever technique is used to actually produce the goods, the technique should have a standard form of reporting progress along with all of the other techniques. This would lead to a lowest-common-level of acceptable reporting and this could easily be embedded in a PRINCE environment (at least, easily in the 2009 version).
The sequence Plan-Do-Check-Act is fine, so long as we add Re-plan/Recycle to it. This would be one of my common principles for all projects.
The real issue, I believe, is how to deal with the real-time interaction with the client in terms of what is wanted and how it should operate. Generally (big generalisation coming!) technical issues are nor the challenge, except in rarefied circumstances. In most business, clarity of needs is an issue. I think that the principle of Timely Feedback needs a little more attention than it currently receives in our industry
Keep up the blogging... it is always interesting.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban