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 80s. 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 knowability 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.

Thanks,

Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility

Technorati Tags: Lean Lean-Agile

tag with del.icio.us