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.

Why Is Planning Difficult? Is It a Waste of Time?

Why Is Planning Difficult?

Why is planning difficult? A lot of people seem to think that planning is very difficult and some think it is a waste of time because even very well-thought-out plans often don’t work out as expected. This issue is important because it is at the crux of selecting a methodology and planning approach for a project. Do I use Agile or plan-driven (aka Waterfall)?

Why Is Planning So Difficult?

Many people seem to think of planning as an “all-or-nothing” proposition – either you develop a highly-detailed plan or you do no planning at all. I don’t believe that to be the case. There seems to be two major problems associated with why people have this difficulty with planning:

Dealing With Uncertainty

Many people seem to have difficulty dealing with an uncertain environment – they want things to be crystal-clear, black-and-white and, in an uncertain environment, they think that it is a waste of time to do any planning at all.

Unrealistic Expectations

A related factor is that many people develop unrealistic expectations about planning.

  • If you develop a well thought-out plan, they expect that it should work every time.
  • Many people are also unrealistic that everything about a project will go absolutely perfectly all the time and
  • Murphy’s Law often contradicts that belief.

Planning Fundamentals

Let’s review some fundamentals about planning. We can learn a lot about how the military does planning.

Planning in the Military

Here are a few of my favorite quotes on planning in the military:

Plans are nothing; planning is everything”  – (Dwight D. Eisehhower)

What Eisenhower is saying is that documented plans should not be considered to be sacrosanct. When people document a written plan, the plan often takes on a life of its own and it becomes the “gospel” that everyone is expected to follow rigidly. However, that should not be the case and that’s not a reason to not do any planning at all. Here are a couple of examples:

  • It would be foolish for a military unit to go into battle without doing any planning at all. You should take advantage of whatever intelligence you might have about the enemy positions (as uncertain as it might be) but you shouldn’t lose sight of the uncertainty in that information.
  • In an American football game (or any other sport you want to choose), the coach prepares his team for what he thinks the strengths and weaknesses of the opposing team are; but, again, that planning is based on very uncertain information and lots of assumptions.

Here’s another quote along the same lines:

“No battle plan survives contact with the enemy”  (Helmuth von Moltke the Elder)

What Helmuth von Moltke is saying is that you shouldn’t expect that a plan won’t change at all once you start to execute it.

An Example

In World War II, Churchill and Roosevelt spent years planning the invasion of Europe that ultimately resulted in the Allied forces landing in Normandy on June 6, 1944. Both men knew that an invasion of Europe was the only way that the war could be won but there was a lot of uncertainty about:

  • Where should the invasion take place? How can the Allies preserve the element of surprise?
  • What’s the best way to do it? What are the odds of it being successful?
  • How many deaths and casualties can be expected?

This was a huge decision that had enormous impact:

  • The fate of Europe and most of the free world at that time depended on this being successful
  • Both men faced some level of opposition at home knowing the large number of casualties to be expected

It took a lot of courage to do this planning and make a decision under these circumstances knowing that there was a lot of uncertainty in the situation and the impact of the decision was so enormous. However, planning was essential – can you imagine what might have happened if the invasion was attempted without any planning at all?
Source: Churchill and Roosevelt Spent Years Planning D-Day

What Does This Have to Do With Agile?

This whole issue about planning is at the crux of the controversy about “Agile versus Waterfall”. Many people see the choice between Agile and Waterfall as a binary and mutually-exclusive choice and planning is at the center of this controversy:

  • Some people in the Agile community might say that its a waste of time to do planning in an uncertain environment and you should just use an Agile approach and let the project plan evolve as the project is in progress
  • Some people in the traditional plan-driven project management community might say that it would be foolish to attempt to do a project of any significant scope without a detailed plan for it to be successful

The truth is somewhere between those extremes – it’s not an “all or nothing” choice and you should adapt the methodology and the level of planning to fit the nature of the project. The level of uncertainty in the project is a big factor in making that choice. In an uncertain environment, it might be foolish to attempt to develop a highly detailed plan but uncertainty is never an absolute and it would be equally foolish not to take advantage of whatever information you might have.

How Do You Put This Into Practice?

A lot of people might see “Agile” and “Waterfall” as totally incompatible with each other. It’s like mixing oil and vinegar – they just don’t mix well. And, if you look at this from a mechanical process perspective, that might be true.

In order to learn how to blend these two approaches together in the right proportions to fit a given situation,

  • You have to understand both approaches at a deeper level and get past some of the strong stereotypes that exist about both “Agile” and “Waterfall”.
  • It’s really a choice of selecting a more plan-driven approach or a more adaptive approach based on the level of uncertainty in the situation and there is a whole spectrum of alternatives as shown below:
Levels of Agility

Rather than thinking of “Agile” and “Waterfall” as binary and mutually-exclusive choices and trying to force-fit a project to one of extremes, a better approach is to fit the methodology to the nature of the project and the level of uncertainty and the planning approach is a major factor in making that determination

Overall Summary

Here’s a summary of the key points I want to make in this article:

  1. Planning is not an “all or nothing” proposition
    • The planning approach should be directly related to the level of uncertainty in the environment
    • Planning in an uncertain environment can be difficult but that should not be an excuse for not doing any planning at all
    • However, to quote Eisenhower, “A plan is nothing – planning is everything” – don’t get locked into thinking that a written plan is sacrosanct and doesn’t need to be changed to adapt to the level of uncertainty in the environment
  2. The level of uncertainty and the planning approach is probably the most important factor in selecting a project management approach for projects
    • Rather than thinking about “Agile” and “Waterfall” as binary and mutually-exclusive alternatives,
    • Its more accurate and more objective to think of a spectrum of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme

Additional Resources

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

What are the Most Practical Ways to Do Project Planning?

I recently participated in an online discussion in response to a question that was asked on “What are the most practical ways to do project planning?” It’s a critical issue and it comes up a lot so I thought I would share some thoughts on this subject.

Ways to do Project Planning – Factors to Consider

In my opinion, there are two very significant factors in determining what planning approach would make the most sense for a particular project:

1. Level of Uncertainty

The level of uncertainty in the project is probably the most important factor. 

  • If there is a high level of uncertainty that cannot easily be resolved, it would probably be foolish to try to develop a highly-detailed, plan-driven approach. 
  • An example would be attempting to find a cure for cancer.  It would probably be foolish to try to develop a detailed plan for that effort. There’s just way too much uncertainty.

That doesn’t mean that you wouldn’t do any planning at all:

  • You would take stock of what you know and don’t know and try to develop at least a cursory plan based on that information and then
  • Continually revise the plan based on what you learn as the project is in progress

2. Customer Relationship

The second major factor is the relationship with the customer.  

  • If you have a contractual relationship with the customer where the customer is expecting a firm set of deliverables for a given schedule and cost, you might be forced into a planning model to try to effectively manage and satisfy those customer expectations. 
  • If there is more of a collaborative relationship with the customer, you probably have a lot more ability to optimize the approach based on the level of uncertainty in the project.

Ways to do Project Planning – Planning Quadrants

Obviously, there may be a conflict between these two factors.  I’ve created a diagram below to show some of the possible combinations of these two factors:

Ways to do Project Planning

Lets look at each of these quadrants individually:

1. Low Uncertainty, Contractual Relationship

This is the area that most project managers are most familiar with.

  • It is the area that is most well-suited for a traditional plan-driven project management model. 
  • In this area, the level of uncertainty may be low enough to permit developing a detailed plan.
  • That plan would be consistent with managing customer expectations in a contractual relationship model.

2. Low Uncertainty, Collaborative Relationship

If the level of uncertainty associated with a project is low, you might develop a more collaborative relationship with the customer; however, that might not be the most efficient way to do the project. If the level of uncertainty is truly low and it is relatively easy to define the project requirements upfront,

  • it may not make too much sense to engage the customer too heavily in a collaborative relationship
  • There is less of a need to further define detailed direction for the project as it is in progress.

3.. High Uncertainty, Collaborative Relationship

This is the area where an Agile approach makes most sense. In this area, instead of trying to develop a highly-detailed upfront plan prior to starting the project, you would probably:

  • Reach agreement with the customer on at least a vision for the project and at least some higher level objectives and requirements that the project must meet, and
  • Then further elaborate those requirements and the plan for meeting them as the project was in progress

It’s easy to see how this kind of planning model may not work well unless there’s a collaborative spirit of trust and partnership with the customer since:

  • It may be almost impossible to accurately define the costs and schedule for completing the project prior to starting the effort; and

  • Further defining the plan as the project is in progress requires a close working relationship with the customer.

4. High Uncertainty, Contractual Relationship

This area is the quadrant that is likely to be most problematic:

Impact of Uncertainty

The level of uncertainty will have a big impact. Attempting to do an Agile project with highly uncertain requirements without a collaborative relationship with the customer is not likely to work very well:

  • The customer may not be committed to actively engage in the project as it is in progress to help elaborate and resolve questions related to the requirements; and,
  • As a result, the project may either get stalled or go off in the wrong direction
Impact of Customer Relationship

Attempting to apply a contractual, plan-driven approach in this kind of environment is also likely to be problematic. There would likely be a very high risk associated with trying to develop a firm, plan-driven contractual relationship based on highly uncertain requirements. What is likely to happen is:

  • The project meets the defined requirements but the defined requirements were wrong, or
  • There are so many changes as the project is in progress that the scope of the project winds up being completely different from what the customer was expecting

It’s easy to see how either of these scenarios might present a very high risk.

Of course, this is somewhat of an over-simplification and all projects don’t fall very neatly into one of these quadrants.  There is a very broad range of scenarios in the middle of this diagram that call for some kind of hybrid approach.

What are the Most Practical Ways to Do Project Planning?

There are a number of conclusions that I think we can draw from an from understanding of this model:

1. There Is Not Just One Way to Do Project Planning

There is not just one way to do project planning. Project Managers who have been heavily indoctrinated in a traditional, plan-driven model and attempt to force-fit all projects to that kind of planning model are likely to not have optimal results.

2. This Is Not a Simple Binary and Mutually-exclusive Choice

This is not a simple binary and mutually-exclusive choice between an Agile and traditional plan-driven planning model. It is much more complicated than that.  There’s a whole spectrum of different possible scenarios and it is a multi-dimensional problem

3. Fit the Planning Model to the Nature of the Problem

The right approach is to fit the planning model to the nature of the problem based on the level of uncertainty and the relationship with the customer.  Attempting to use a single “one size fits all” planning model for all projects is not likely to work very well.

Overall Summary

This creates a big challenge for project managers to learn how to blend an Agile and traditional plan-driven approach in the right proportions to fit a given situation.  That’s not an easy thing to do. PMI still treats these two areas as separate and independent domains of knowledge with little or no integration between the two.  This is exactly the challenge that my Agile Project Management training is designed to address.

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.