An Overview of Lean Software Development

October 4, 2009 — Posted by Al Shalloway

In starting out this series of blogs on Lean I intended to go through the sequence I feel is best for people to understand what Lean Software Development is.  However, after having started this I realized a quick overview - to create a road map would be best.  Some of this re-thinking is also because I believe I can turn this series into a short book I believe I'll call Lean Software Development Explained (as some of you know, I like explaining things).  Anyway, here goes.

There are many ways to describe Lean (now I mean lean in general, not Lean software).  Womack and Jones have one way (flow based), The Poppendiecks have another (eliminating waste, optimizing the whole, respecting people, ...), Don Reinertsen has yet another (flow based product development), Jeff Liker has yet another (sociological) and I am sure there are any number of others. At Net Objectives, we, of course, have our own (Business Driven Software Development - a combination of all of the above).  It is not that one is better than the other as much as each provides a different perspective on Lean.

Lean is more of a thought process than a set of tools (see Lean is more than a set of tools). It is a mindset based on a foundation of beliefs that are often not mentioned - and often not believed in the software arena.  It is important to understand this belief set before going down a path of implementing any part of Lean.  

Fundamental Beliefs of Lean

Lean has (at least) four fundamental beliefs.  There may be more, but these are what I've distilled so far.  When I say fundamental, I mean these are the  beliefs that one starts with. If one does not agree with these beliefs, then one can only use the tools of Lean that they agree with, they cannot use the thought process of Lean (at least not effectively).

Lean is based on systemic thinking.

While this shows up as PDCA (plan-do-check-act) at Toyota, the underlying thought is that it is not all art or creativity or magic but a process that can be understood. In other words, there is a science underneath our work.

It is essential to respect the people doing the work and give them an opportunity to contribute.

This, combined with the earlier belief, is why I often say Lean is based on Deming's system of profound knowledge. We must apply systemic thinking to improve our work and the people doing the work are the best ones to understand it.

Work-in-process (WIP) is a liability, not an asset.

One of the biggest contributions of Toyota was noticing that inventory was not an asset but rather contributed to errors and costs and lower quality.  By treating inventory as a liability, you strive to reduce it.  This has the effect of lowering costs, raising quality and speeding up the process. Toyota's Just-in-time approach is their approach to lowering inventory. In software this WIP is comprised of requirements started but not completed and being used.

One should drive from economics

Deming's first of fourteen points is "Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs."  Taiichi Ohno talks about adding value to the customer.  The assumption is that the purpose of the enterprise is to be profitable while adding value to the customer.  This is far from an Enron style approach where it was just about making money (no value to the customer was necessary).  It is also quite different from certain defense contractors and utilities that are on a cost-plus basis and have no incentive to lower costs. As an aside, I will point out that this attitude is very humane in that the most humane thing a company can do for its employees is provide continuous employment with a great working environment (as implied from a prior fundamental belief).

A Note on These Beliefs

I am not claiming that all of these beliefs are true (although I think the first 3 are). Some of them reflect reality but some of them reflect the attitudes of those doing Lean.  Not all Agilists believe in these (particularly the first and last).  This is why I say Lean and Agile are not the same.  Many in the Agile community are not Lean by any means (in particular, those who believe in focusing mostly on the people involved).  Many others are completely consistent with Lean even if they don't use the term.

Another aside may be useful.  Lean does not imply one only needs to focus on the system.  It means the net effectiveness is the product of the quality of your system and the quality of your people.  You must focus on both.  Good people in a good system is the goal.

The Rest Is Implied

Lean could be said to be figuring out the best way to have people work as efficiently as possible to deliver the greatest value to the customers of the business. That is, how do we best implement these four beliefs?  In this way, Lean is an approach based on a mindset.  However, people have been doing this for quite some time so that there are a lot of useful tools that are present. But one should not confuse Lean's tools with this mindset.

The Lean Enterprise - A Fairy Tale

Let me tell you a fairy tale.  Imagine a company where people worked without waste.  Where leaders created a vision of what the company was up to and selected the best strategies for the organization. Where managers supported their workers by creating the proper organizational structure for them to work in and where the workers were continuously improving how they added value to the customers of the organization.  The right products were developed at the right time with higher quality and lower cost than the competition. This does not have to be a fairy tale - but getting there is hard work and takes a lot of determination - at all levels.

Transitioning to Lean

How does one get to be a Lean organization?  I wish I could say it were easy.  But it isn't.  I wish I could say that most companies want to do this.  But they don't.  Fortunately, one can transition to Lean.  One does not have to do it all at once (although if one is willing to do that I would not want to slow them down).  Instead, it is possible to transition to Lean in stages. 

While Lean does not really decompose - it is highly interrelated and somewhat holistic - it is useful to think of Lean as having three different components to allow for a better transition to it.  I look at Lean as being composed of:

  • Lean-Science (or, better said - Flow Based Product Development)
  • Lean-Management (how managers must "manage" in Lean organizations)
  • Lean-Knowledge Stewardship (becoming a learning organization)

I make this decomposition because getting some facility in the first (flow) leads to the second (management) which leads to the third (a learning organization).  It is based on the notion that while one wants to create a culture of trust, working on culture directly is not possible.  Instead, one must work on the management system of an organization since culture reflects this.

One can therefore start with the simple notion of following Lean-Science (product development as flow).  This doesn't require a culture or management change.  It simply means to take advantage of what has been learned about using time as a basis for making decisions instead of trying to manage productivity directly.

Having a common understanding of what improves the team opens the possibility of teams and management working together.  It also provides guidance to the business side of the organization in how to best select products to be created or enhanced.

In Summary

Lean is based on the notion that we must use systemic thinking in adding value to our customer as soon as possible, eliminating delays when possible.  Those doing the work must do this.  Those "managing" them must create the proper organization that allows for them to do the work.  We can start with using the notions of flow at any level in the organization.  By having a common thought model throughout the organization and at all levels in the organization a true basis for teamwork with proper vision at all levels can emerge.

I will go through each of these different steps in more detail in future blogs as well as start organizing all of these blogs into a cohesive explanation of Lean Software Development.  Please stay tuned and provide feedback.

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


Hi, Mr Allan.

I've been working in projects where the focus was on completing engineering activities. Something like Activity Driven Software Development (Waterfall).

When we tried to become agile, we start to focus on running software. Now, our focus is working software, but I've found something evil there. We are doing something like Completing Modules Driven Development. And we have working software but it is incomplete to be releasable to the client. The business again is waiting for us.

I think that we must re-think our strategies to complete work. When you mention Business Driven Software Development I think in focusing on develop complete business cases to be able to release it. Could you explain BDSD in a nutshell or twitter way?

Thank you...

Business Driven Software Development means to let the business needs drive the software being developed.  This may sound obvious, but it isn't usually done.  Instead, many IT organizations see how they can enhance their systems and then the business side sees how to use these enhancements. BDSD is consistent with your comments too.  We are only interested in capability that is actually utilized.  There is no value until that is done.

Alan Shalloway, CEO Net Objectives

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