The Foundations of Lean (and Kanban)

October 2, 2009 — Posted by Al Shalloway

I hadn't meant to imply that the page or two on the essence of Lean of my earlier post covered the scope of Lean.  In this blog, I'll talk about two foundations of Lean - systems thinking and respecting people.  This will open the door for follow up blogs on Lean-Management and Lean-Learning (continuous process improvement).

Systemic Thinking and Respecting People.

I like George Box's quote - "all models are wrong - some are useful."  I am more interested in useful models than if they are literally true.  I studied Deming in the 80's. This put in me good stead when I read the Poppendieck's books.  One cornerstone of Lean is that it takes a systemic approach.  That is, there are rules on which the work we are doing is based.  Plan-Do-Study-Act means we can plan our work, see what happens, study it, learn and react (act) to what we've learned.  This is a scientific approach.  We continuously refine our knowledge.

Taiichi Ohno added just-in-time and autonomation on top of this.  Just-in-time basically says don't do things before they are needed because to do so is wasteful.  This insight was arrived at by realizing that inventory is a liability not an asset.  In the physical world of car production inventory are your partly made cars.  In the world of software development our "inventory" is our work in process (WIP).  WIP is to be minimized because it leads to waste and adds to risk. I'll talk about autonomation in another blog.

Another cornerstone of Lean is that we must respect people.  In this regard, Lean is very humane.  We want people to take advantage of their intelligence. These two go together in an interesting way.  One of Deming's 14 points was "Remove barriers to pride of workmanship." By providing a way for people to contribute how to do their work better, Deming (Lean) contributes to the satisfaction people get from their work.  But there is more to it than this. 

Putting systemic thinking and respecting people together implies that the people close to the work do the work.  This is the notion of self-organizing teams.  One can't tell people what to do - they must do what works for them.  This doesn't mean, of course, that you can't coach them.  Those new to Lean would be better off if you do that. But why does this work?  In other words, why is it that we can have those close to the problem figure things out and have that work for the organization? I would suggest it is because there are rules that the world (including software development) works by.  Don Reinertsen has outlined many of these in his two excellent books Managing the Design Factory (12 years old but still 8 years ahead of its time) and The Principles of Product Development Flow: Second Generation Lean Product Development

This doesn't imply there is one best way (Taylorism). What it implies is that the way to do things is knowable or at least we can improve our knowledge of it ;) .

I would suggest that the combination of respecting people and taking a systemic approach is a powerful one.  People close to the work know what is happening.  But, because we are taking a systemic approach and because each team in a value-stream is related to other teams in the value stream this systemic view can be done in such a way that people can coordinate together.  This does not mean a higher view is not necessary, but it does mean that alignment across teams is possible.

This has three implications which I will deal in three different blogs (shortly I hope).

  • explicitly working on the team's process creates visibility of it to management (I call this transparency)
  • working together increases the learning capabilities of the team (facilitating a learning organization
  • understanding product development flow allows different parts of the organization align their work

Please let me know if writing short blogs in succession like this (this is the third in a week) is better than longer ones every week or so.


Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility


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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


I prefer the shorter ( ahem, leaner ) blog posts

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