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 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 (available below) is a depiction that as we go further into the future there is more that we are uncertain about. There are so many other factors that may impact a project in 6 months time that we just don't know about current. For example, Apple/Google may update their software requirements or a particular plugin we were planning to use has reached end of life.
This is why it's important to break down the project into smaller builds. Each build can be scoped at the relevant time allowing greater certainty around the estimated length. This is the premise of agile software development but it helps to understand the 'why.'
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.
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 mitigate risk throughout the brief and scoping process, it generally reduces the estimation, which brings the overall cost of a project down.
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.