An Agile Approach To Dealing With Uncertainty
Every new project carries an unimaginable amount of uncertainty. Usually the most common sources of uncertainty are requirements and technology. The first one is related with the business opportunities and what is the right problem to solve for the right people. While the second aspect has more to do with the current characteristics and capabilities of the technology adopted, as well as the ability to produce quality software taking in consideration the dependencies with all the teams that are usually involved in an initiative.
Risk or Uncertainty?
Risk is when we don’t know what is going to happen next, but we do know what the distribution looks like and Uncertainty is when we also don’t know what is going to happen next, but we don’t know what the possible distribution looks like.
As you may have noticed, risk and uncertainty are not the same thing. While risks can be measured and controlled, uncertainty is by that definition unmeasurable and uncontrollable. We can say that risk is a kind of uncertainty whose probability distribution is known or can be calculated. To manage risks there are several good practices for identifying, analyzing, prioritizing and finally giving them proper treatment that may include, among other things, one of the following risks responses:
- Accept: Undertake no action to manage the risk, but instead have a contingency plan in place. (e.g., rely on backups instead of implementing code to protect against data loss)
- Reduce: Take measures to decrease either the likelihood or the impact of the risk (e.g., implement software capable of dealing with a higher number of transactions per minute)
- Transfer: Share/transfer the risk to other parties who usually demand a fee for assuming the risks (e.g., outsource difficult work to a more experienced company).
- Avoid: This is the process by which you reduce the risk exposure by avoiding or eliminating the activities (e.g., remove a small part of a project which carries a large risk factor).
Agile Project Management Frameworks by default take advantage of the Reduce strategy to respond to risks by delivering incrementally. Scrum sprints, for example, is a well-known approach to risk reduction by facing and assessing financial, business and feasibility risks in short iterations. Well established Agile initiatives have been achieving great results with this approach.
For now, there is no more to say about risks given that there are many good articles on this topic, let’s move on to the second part.
Cone of Uncertainty
The Cone of Uncertainty, described by Steve McConnel, states something that all experienced software professional knows by heart. The sooner we have to answer about the end date of a project, the wronger our answer will be. That’s because virtually no two projects ever shared the same requirements, people, business context, technology and constraints. Again, Agile Frameworks have a good response to the Cone of Uncertainty by implementing small pieces of the software that will allow the team to estimate better the future activities of the project as seen in the picture above represented by the spikes options 1, 2 and 3.
A Practical Guide to Lowering Uncertainty
In the previous parts you saw the theory of managing uncertainty and that’s good, however, the real-world of the software projects is much more complex than that, so let’s get our feet wet.
I will now propose a simple but effective technique to start managing uncertainty which I’ve learned from Bruno Fernandes at OutSystems. Remember that uncertainty is not always a bad thing and many opportunities may come from it. The key to dealing with uncertainties is to anticipate the point in time that you lower or eliminate it, so you can take informed decisions as early as possible.
Do not even try to manage uncertainties for very small or well sliced initiatives for the simple reason that the frequency of the delivery of those kind of initiatives mitigates the uncertainties by default. If this is your case, maybe you should continue reading this article — that may help you in future projects.
The steps are easy to follow but watch out for tricks and common pitfalls when trying the technique for the first time.
- 1. Recognising Uncertainties : Make a list of possible uncertainties. I’m sure you can think of a big list of uncertainties but in case you lack ideas I’ll provide, at the end of the article, an Uncertainty Assessment template where you can find a short list of common uncertainties. Give each uncertainty a relative weight based on how much impact it could have in your project. (1st time tip: keep the list of uncertainties short to prevent spend hours in the step 3)
- 2. Getting the Roadmap: List the project deliverables with its respective estimated due dates. It can be the User Stories, Requirements, Milestones or any kind of items you plan to delivery in the initiative.
- 3. Correlating Roadmap vs Uncertainties: As a team, start mapping each Roadmap item to each of the uncertainties you have in your list.
- 4. Make the Uncertainty Visible: After the first 3 steps you will have all the data you need to build a chart showing the level of uncertainty along the time as you can see in the picture below. The formula is simple and I’ll provide a spreadsheet template at the end of the article.
At this point the team realises that they have in front of them a scenario of high uncertainty until delivering the Milestone #7. At that point may be too late to take any decision in order to put the initiative back on track or even abort the project without losing much money.
- 5. Work to Reduce Uncertainty: Now it’s time for the team to get together, look at the chart and start thinking about how they can reduce the level of uncertainty earlier in time. The techniques to do that are usually to build PoC, spikes, prototypes, interviews and so on.
It’s important to identify what’s the root cause for the uncertainty, for example, in the above chart there was something delivered in Milestone#7 that carries lots of uncertainty and the team must discuss what it is and what actions should be done now to potentially eliminate or reduce uncertainty. (1st time tip: It is ok to add work in order to reduce uncertainty, but make sure to make it clear to the main stakeholders and sponsors) - 6. Re-evaluate & Compare: After identifying the actions to reduce/eliminate the main sources of uncertainty, the team must add the mitigation activities to the roadmap and re-evaluate the remaining level of uncertainty of all the milestones of the initiative. They can overlap the information and the result would be something similar to the chart below.
Now it’s possible to see that at the end of the Milestone#2 there’s a significant reduction of the uncertainty level, which will allow the team to take an informed decision much earlier on time. Besides that this approach may save time and money, it can be the turning point between the success or failure of an initiative or a Startup.
Takeaways
All software projects carry a very high degree of uncertainty and that is the beauty of this kind of endeavour. The same uncertainties that give us sleepless nights also have the ability to differentiate us from the competition. We can call this kind of uncertainties, opportunities.
As I’ve mentioned before the Agile mindset enforces short feedback loops and you must take advantage of this approach in order to get as much valuable information as you can in a short period of time.
I’ve proposed an easy six-step approach to deal with uncertainties that was already applied and works, but remember that the most effective way to reduce/eliminate uncertainty is to put the software in the hands of your real users.
Below you can get an Uncertainty Management template to use in your initiatives. Please share your thoughts and comments!
