What is the Lean Startup Approach? How Does It Relate to Agile?

What Is the Problem?

The “Lean Startup” approach is based on a book by Eric Ries of the same name. The fundamental problem that the book addresses is that many companies:

  • Think that they know what the market and their customers want,
  • Make a lot of assumptions based on that thinking
  • Launch a long and expensive product development effort to meet what they think are those needs, and
  • Then find out that those assumptions were wrong

That approach is typical for a company with a traditional plan-driven approach to project management. (That is what many people loosely call “Waterfall”). The problem isn’t really unique to startups; this problem can take place with any company of any size – it may happen more frequently with startups just because there is normally a higher level of uncertainty associated with a startup.

What’s the Solution?

The solution to this problem is to use an incremental and iterative approach to product development. That approach should have lots of customer input and feedback along the way. That approach is exactly what is used in an Agile product development effort. The approach would look something like this:

It’s easy to see how this approach can significantly reduce the market risk associated with new product development. And, it is appropriate for any company (not just startups).

  • Instead of committing to a long and expensive development process on the basis of some limited number of assumptions that may later to be wrong;
  • It treats those assumptions as only a “hypothesis” and seeks to validate those assumptions (hypotheses) as the project is in progress.

How Does This Fit With Agile?

The product development approach recommended by the Lean Startup method is essentially the same as an Agile/Scrum product development approach. It is based on an incremental and iterative development process with lots of direct customer input and feedback.

  • The Lean Startup approach goes somewhat beyond an Agile/Scrum approach.
  • The approach focuses on how the business strategy behind the product is developed and validated, which an Agile/Scrum process does not directly address.

In practice, this concept can be applied at many different levels. It is not limited to a single product development effort and it is not limited to startups. There are potentially multiple levels in any enterprise-level Agile implementation as shown in the diagram below:

The implementation of this is really at a higher level than the development process. It is at a business strategy level and a product strategy level. At each level in an enterprise:

  • There may be different levels of uncertainty and
  • Each level may call for a different planning approach based on the level of uncertainty at that level

Planning in an uncertain environment can be very difficult. Here’s an article that goes into that in more detail:

Overall Conclusions

The “Lean Startup” approach is a good, common-sense approach to planning that is very appropriate for an uncertain environment. It acknowledges the level of uncertainty in the environment:

  • Rather than glossing over the uncertainty and making assumptions about it to try to make it go away
  • It uses an incremental and iterative development effort to validate those assumptions as the project is in progress

This approach is not unique to startups; it can apply to a company of any size and level of maturity. It can also be applied at any organizational level and any level of planning and management in a company based on the level of uncertainty in the company at that organizational level or level of planning and management.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Management of Uncertainty in Agile Projects

One of the biggest inherent advantages of an Agile approach is the management of uncertainty in Agile projects. To understand this better, we need to first understand the difference between:

  • An Empirical Process Control Model and
  • A Defined Process Control Model

Empirical and Defined Process Models

A key thing to understand in this context is the difference between and Empirical Process and a Defined Process.

Empirical Process Control Model

Agile is based on an empirical process approach – the word “empirical” means “based on experiment or observation”.
When you use an empirical process approach,

  • You accept that you don’t know everything you might want to know about a project before you start and
  • The process is designed to adapt both the solution and the process to discover the solution to learning as the project progresses.

Defined Process Control Model

A “Defined Process” is repeatable and doesn’t change significantly from one project to the next and

  • Is very predictable in the results it produces while an “Empirical Process” is specifically intended to favor adaptability over predictability.
  • For that reason, an empirical process is much better suited for a project with high levels of uncertainty.

Uncertainty in Agile Projects

A very powerful concept for understanding uncertainty in Agile Projects is the “Stacey Complexity Model” which is shown below:

Uncertainty in Agile Projects

There are two dimensions of uncertainty in this model:

Requirements Uncertainty

One dimension is requirements uncertainty – How well understood are the goals and requirements for the project and how certain are the customers that they know what they want?

Technology Uncertainty

The other dimension is technology uncertainty – How well understood is the technology solution to the problem and what is the level of risk associated with the technology solution?

This is a very important concept because the ability to handle uncertainty is so important in today’s most critical projects and heavily plan-driven projects are not well-designed to deal with high levels of uncertainty.

Management of Uncertainty

What typically happens in a plan-driven project is the project manager tries to reduce the level of uncertainty to an acceptable level before starting the project by:

  • Trying to resolve any uncertainties in the requirements as much as possible before the project starts, and
  • Trying to eliminate as much technology risk as possible

This often results in using tried-and-proven technology and doesn’t push the envelope too far in terms of going into areas of new and undefined user requirements. The downside of that, of course, is that the technology approach may wind up being obsolete within a relatively short amount of time after it is released and it may also result in a very mediocre user experience with the solution.

What Does “Managing Uncertainty” Mean?

Let me clarify what I mean by “managing uncertainty”.

  • To some people, uncertainty is like a cancer that attacks a project and can cause it to fail. Conventional project management thinking has reinforced this approach to reduce the risk and uncertainty in a project as much as possible
  • I don’t see it that way uncertainty can also represent opportunity to go beyond what is expected and the value a project produces is many times directly related to the risk and uncertainty in the project
  • If you force a project to fit into a plan-driven model by reducing the risk and uncertainty, you may be maximizing the predictability of the project to meet cost and schedule goals but minimizing the value that the project produces

Here’s another article with more detail on this:

Overall Summary

Here’s a summary of some important points:

  • Uncertainty should not be ignored and not managed at all. Uncertainty often is directly associated with opportunity
  • Fortunately, this is not a black-and-white decision between:
    • A totally rigid, plan-driven approach with almost zero uncertainty and
    • A totally adaptive approach with an extremely high level of uncertainty.

The right thing to do is to fit the approach to the level of uncertainty in the project rather than force-fitting a project to some kind of canned approach (whatever it might be). It takes more skill to develop an intelligent approach for managing uncertainty; it requires:

  • The ability to objectively assess the level of uncertainty in a project
  • An understanding of both empirical and defined process models
  • A deeper understanding of the principles behind these approaches to know how to blend the two together to fit the situation

The ability to do that is the essence of what I believe is an effective Agile Project Management approach.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.