Software Intensive Systems
Lean Development

Dr. Robert Charette developed the principles of lean development (LD) in the early 1990’s as an outgrowth of ITABHI Corporation’s project software intensive systems risk management, program management and enterprise risk leadership efforts. While none of lean development's basic principles are new in and of themselves, their coherent integration under the banner and goals of LD make them particularly powerful. In fact, it is the emergent "virtuous cycle" property resulting from the interaction of its total set of principles where lean development's power lay. 

LD isn’t for most organizations since the process requires foresight, deep understanding, and significant commitment on the part of an organization's senior management. Lean development challenges business executives, marketing managers, program managers, software managers and developers, especially those wedded to capability maturity models, to rethink their assumptions in regard to delivering business value to their customers through information technology.

Why Do You Develop Software the Way You Do?

Have you ever questioned the assumptions that underlie your software development practice today? If not, why not? Have you asked yourself whether there is a better way to create and use software-intensive systems? If so, have you looked at lean development?

Lean development (LD) is a strategic as well as tactical business approach for the creation of change-tolerant business software intensive systems—i.e., systems that can rapidly adapt to or help in the creation of business change—in:

  • 1/3 the human effort
  • 1/3 the development hours
  • 1/3 the time
  • 1/3 the investment in tools and methods
  • 1/3 the effort to adapt to a new market environment

than “conventional” approaches – e.g., SEI CMMI/CMM Level 3 rated organizations – to software-intensive system development.

Why the 1/3 targets? Because these goals are meant to challenge status quo thinking about the nature of developing software. Without audacious goals, ones that seem impossible to reach, software and business managers won’t bother to think about the issues of software development in entirely different ways.

Principles of Lean Development

Lean development is a principle-driven approach, and is part of the agile approach to software system development. However, LD is a strategic, business-down approach whereas most agile approaches are tactical, program team-oriented in nature. 

The twelve core principles of LD are:

1. Satisfying the customer is the highest priority of the organization.

The lean development team must focus on determining the customer's business value proposition. The goal is maximizing customer satisfaction through creating real business value at an acceptable level of technical quality. Not meeting customer value expectations is viewed as failure.

2. Always provide the best value for money.

Software intensive systems should help eliminate a customer’s risk, solve a problem or provide them a new opportunity at a reasonable cost. Value is the goal, not perfection. Value is a combination of product features which meets a customer’s needs at a specific time in a specific situation for a specific price.

3. Success depends on active customer participation.

Active participation is a collaborative, joint effort, not token integrated product teams. Customer participation is more than just “buy-in;” active participation is essential to adapting to change and making real-time business and technology trade-off decisions.

4. Every lean development is a team effort.

Multi-disciplinary teams rather than isolated individuals are needed because diversity is critical to innovative, fast-cycle time development.

5. Everything is changeable.

For software intensive systems to be useful, they must meet rapidly changing business conditions. Lean development assumes that requirements changes will be continuous and that learning to adapt to changes is a better strategy than trying to control them. The constant questions asked in a LD effort are, “What kinds of changes could occur? What would we do if they occurred? How can we build the system to be more tolerant of this type of change?

6. Domain, not point solutions.

One-of-a-kind software systems are too expensive in most cases. Software intensive systems that are applicable across multiple domains—companies, markets, products—spreads the cost and therein contributes to the value equation.

7. Complete, don’t construct.

Construction of software systems is time-consuming, costly and fraught with error. Buy rather than build has long been a viable strategy for most application development groups. Whenever possible, use pre-existing or pre-fabricated software elements to minimize organizational opportunity costs.

8. An 80% solution today instead of 100% solution tomorrow.

Markets are moving too fast to provide 100% customer solutions.

9. Minimalism is essential.

Lean development eliminates needless overhead and waste. LD seeks to eliminate waste by minimizing paperwork, keeping development teams small and co-located, and keeping the product scope focused.

10. Needs determine technology.

Chose the objectives of lean development then the technology to support it, not visa versa. The technology options today are so vast that it is easy to spend more time changing technologies than creating business and customer value.

11. Product growth is feature growth, not size growth.

The critical factor in LD is delivering change-tolerant features. When evaluating new features, the team should always consider how business practices might change and either effect or be effected by the software application. Size is not the issue.

12. Never push lean development beyond its limits.

Lean development aims to increase revenue, reduce costs and increase profits by creating increased customer value. If there are better ways of doing so than lean development, use them.

There is an unwritten but important 13th lean development principle that supports the concept of humanware as well. In performing lessons-learned studies, the Japanese discovered that process and technology improvements on the factory floor contribute only 25% towards the overall improvements lean manufacturing creates. Humanware issues account for the rest. Like lean manufacturing, lean development depends on an ideology that engages those involved in it mentally and emotionally. Those using lean development need to achieve satisfaction through their work.

If you are interested in learning more about lean development, contact ITABHI today at You can also read more about LD in Jim Highsmith’s book, Agile Software Development Ecosystems or in the Cutter Consortium Executive Report Challenging the Fundamental Notions of Software Development.