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
You can find more detailed information on empirical and defined process control models here:
Uncertainty in Agile Projects
A very powerful concept for understanding uncertainty in Agile Projects is the “Stacey Complexity Model” which is shown below:
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 level of 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:
Tips for Managing Uncertainty
You often have to make informed decisions based on very uncertain information because waiting for the information to become more certain might significantly delay the project or might not make sense at all. The approach that seems to work best is to separate the “known” from the “unknown”, make some hypotheses or assumptions about the unknowns if necessary, and then evaluate the risks of going forward based on those assumptions or hypotheses. If you do decide to go forward, you shouldn’t forget that those assumptions were only assumptions and may need to be revalidated later on. (Many people often forget to do that) In a traditional project management environment, a risk register or something equivalent to that might be used for that purpose – that level of formality may or may not be necessary in an Agile environment, but the principle is nonetheless important.
An Example of Managing Uncertainty
There’s an art and a skill associated with making decisions in an uncertain environment. Anyone who has done any gambling where you have to bet on the outcome of an unknown event (like what card you’re going to be dealt next) will understand that. Here’s an example: most people are familiar with the game of “Blackjack” where the players play against the dealer and both try to win by getting the highest possible hand without going over 21. Suppose I have been dealt two cards and have a total of 16 points in my hand and the dealer is showing one card as a “10” with the second card face down. There are several very significant things I don’t know:
- I don’t know what the dealer’s second card is because it is turned face-down
- I don’t know what card I might be dealt next
Both of those are significant unknown’s but I have to make a decision anyway. I can make an assumption that the dealer’s second card is either a “10” or a face card (Jack, Queen, or King) for a total of 20 points. That assumption seems to make a lot of sense because there are more ways for that to happen (Ten, Jack, Queen, or King) than any other individual card. If I make that assumption, I know that my 16-point hand is going to lose against his 20-point hand and the best course of action would be for me to take a hit and risk going over 21 because I’m going to lose anyway if I don’t take a card or I don’t do anything at all.
That’s an example of an informed decision – I separated the known’s from the unknown’s and then made a reasonable assumption about the unknown’s based on the risks I saw in the situation. The alternative would have been to make no decision at all because the unknown’s were too significant or to make a “shoot from the hip”, uninformed decision to do something without doing any real analysis or really thinking it through at all and without taking advantage of the facts I do know in order to make a decision. I think that one of the most important factors for doing that effectively is to make an honest and objective assessment of the situation. There are several errors I have seen often with this:
- Overestimate the level of confidence in what is known and make a poor decision based on incomplete information
- Make an assumption about incomplete information, make a decision based on that assumption, press forward, and then forget that it was an assumption and never retest or revalidate it later
- Ignore whatever known information is available for making a decision and just proceed forward based on an uninformed decision without taking advantage of what is known
Overall Summary
There are two primary problems I have often seen in this area:
- Analysis Paralysis – Delaying making commitments or delaying making any decision at all until the information required to make the decision has a very high level of certainty about it and all of the risks associated with a project are well-known and completely understood. This is often associated with the traditional, “Waterfall” style of project management. Unfortunately, this mode of operation has been the norm in some companies that are very control-oriented and insist on accurately knowing the cost and schedule of a project before making a significant commitment to it.
- Cavalier Approach – The opposite of that can be to take a very “cavalier” approach to not worrying about managing uncertainty and risk at all, just start doing a project with very little or no upfront planning, and assume that whatever uncertainty and risk is inherent in the project will be discovered and somehow work itself out as the project proceeds. This is the approach I’ve seen on a number of Agile projects.
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.
Related Articles
Check out the following related articles on “Agile Planning”:
- What is the Lean Startup Approach? How Does It Relate to Agile?
- Why Is Planning Difficult? Is It a Waste of Time?
- What are the Most Practical Ways to Do Project Planning?
- Management of Uncertainty in Agile Projects
- Agile Estimation Practices – What Is the Role of Estimation In Agile?
Additional Resources
Resources for Agile Project Management Online Training.