×

Dealing with risk when using agile to develop software

by Oliver Armstrong, Nov 07, 2019

Risk, it is everywhere and no matter how hard you try, it is impossible to escape. To deal with the inevitable risk that comes with the software development process, we must find ways to identify, mitigate and accurately allocate time to risk. This enables a team to keep to project timelines and not have them blow out. This article will outline how we approach risk throughout the various stages of agile development and the steps we take to de-risk our projects. There is risk under every stone throughout the software development process, so we will only be touching on a few of the places where risk is found and how best to deal with it. The Way of Working is how WorkingMouse manages risk. See how introducing a Way of Working will improve your software development projects.

The Cone of Uncertainty

The beginning of any software development project is by far the riskiest time for all involved if not approached from the right angle. The Cone of Uncertainty is a depiction of the level of uncertainty around the length of time required to complete a project based on the amount of knowledge at the beginning of a project, and the risk of the project time blowing out due to this uncertainty.
Before the project begins, uncertainty is at its highest. Asno work has been completed yet, the project team has only past experience tobase their estimations on. In agile software development, no two projects are thesame, meaning that even with years of experience it is impossible to provide anexact estimation. When combined with the fact that product requirements arelikely to change in every agile project, it makes estimating very difficult.

Our x-axis on the Cone of Uncertainty is the time in thefuture we are trying to predict. We can see that the further out from where weare currently, the more risk that is associated with that prediction. Our aimis to estimate out to our “sweet spot”. We find this is about 8 weeks into thefuture. This enables us to be confident in the estimations we make withouttaking on too much risk.

Using the cone of uncertainty in your projects

The cone of uncertainty isn't just a visual depiction of how risk is measured in software development, it can also be used as a useful tool in your arsenal to help explain the impact of the varying software development approaches, agile (fixed time or fixed scope) vs waterfall. 


The cone of uncertainty is a great way to reinforce why agile is such a beneficial approach to software development. Utilising shorter iteration cycles working towards a milestone with scoping sessions to map out the next development cycle enables us to keep the estimations in that sweet spot throughout the life of project rather than estimating too far into the future.
We utilised this very approach with one of our clients. We were able to bring the Cone of Uncertainty into the conversation early on to show them the benefits of using an agile approach over fixed time and materials (waterfall). Often this perspective shift for clients away from having everything delivered at once to working iteratively is the most difficult to convey. The Cone of Uncertainty can make this discussion more visual and easier to digest the benefits of agile development through the eyes of risk. Understanding the Cone of Uncertainty and how it applies to a project is also beneficial to a client. When we can remove any risk throughout the brief and scoping process, it also reduces the estimation, which brings the overall cost of a project down.

Risk rating and tech spikes

The tech spike allowance creates a bank of time which can be drawn upon when the project team needs it. The tech spike allocation is used as a chance for the team to take time to research or test concepts before they estimate properly on something. Typically, it is a project team member that indicates the need for it, though all tasks with a risk rating higher than eight must be de-risked before estimating, which is almost always reduced through the completion of a tech spike.
A tech spike can be included in the development process in two ways: Case 1 - If the issue being estimated has a high priority and cannot be moved into another iteration, then the other option is that a tech spike for the issue can slot in before the next iteration as a chance to research before estimating. Case 2 - the issue can be moved into a later iteration, and a tech spike can be put into the next iteration in its place (this option doesn't interrupt the development flow).
Our risk rating and its score is what will initiate a tech spike. As mentioned above, if the risk score associated with an issue is above an 8, a tech spike is required to de-risk the task before going into development. We apply a risk multiplier using the unfamiliarity and complexity of the issue to the team. This gives us our risk score out of 25. If this score is above an 8, a tech-spike is then required. We then use a Fibonacci like sequence to get the general size of the task which we multiply with our risk score to get our time estimation for that task. 

Using risk rating and tech spikes

Risk rating and tech spikes are used extensively during the internal development of Codebots. Our team working on Springbot made great use of tech spikes and risk ratings when implementing relationships to the bot. They found it useful when estimating for features when they were unsure of the details or technologies. It can provide the insight into if a tech spike is required or just more research and time allocated. In the case of our relationship implementation, the idea wasn't completely foreign to the team so when it came to assigning a risk they discovered (while the risk score was just below an 8), extra time was needed to be allocated to ensure any unknowns could be handled within the expected delivery timeframe. This ended up being extremely valuable to the team as throughout the implementation, as issues cropped up during development. If it weren't for the appropriate rating of risk and allocation of time, deadlines would have been missed.