Project Risk Management with Agile

“Trying to predict the future is like trying to drive down a country road at night with no lights while looking out the back window.” — Peter Drucker

Traditional project management mitigates risk by plotting out the entire project in advance, trying to guess what might happen in the future.

Agile does it by observing what’s happening now. Agile focuses on delivering small batches of the highest priority work in short iterations so you can give your customers valuable working software. You base future work on how customers actually use the software, inspecting and improving your product and processes with every iteration.

By basing your risk management on knowns rather than unknowns, you do only the planning and mitigation that’s required.

Agile: pragmatic tools for project risk management

KPMG New Zealand’s Project Management Survey 2017 found that traditional project management approaches aren’t working. Around two thirds of New Zealand projects fail and only 21% deliver on benefits.

Gina Barlow, Director in the Advisory team at KPMG New Zealand, stated: “The survey shows that current project management methods are struggling to provide efficient project delivery, so there is a need for project management to take a big step closer to business strategy and agile project management.”

The 2018 Standish Group Chaos Report found that only 33% of software projects were successful. It reported that Agile projects enjoy a 60% greater chance of success than non-Agile projects.

With Agile now best practice for software development, it is essential to understand how we can use Agile approaches and tools to manage and mitigate risk.

When we talk to organisations about the benefits of Agile software development, all too often we get the response that the current priority — Big Project X — is too important to fail and that Agile is too risky. This is despite the fact that their current methodology is not delivering what they need. The problem is often that they know traditional project management but don’t know Agile. Seeing how Agile techniques let you manage and mitigate risk will help you understand how an Agile approach reduces risk, rather than increasing it.

Once organisations see how they can reduce risk by working in an Agile way it becomes the obvious choice for Big Project X.

In this guide we will summarise:

• The four different kinds of risk faced by software development projects
• The Agile project risk management model
• How we can use the project risk management model to reduce risk

To help you check how well you’re currently managing risk, and to guide future improvements, we’ve created an Agile project risk management checklist.

There are many risks in software development projects, some of them generic and others specific to a particular project and situation. We will look at four of the most common and obvious risks that apply to almost all software projects.

1. We will fail to deliver the quality that our market needs.
2. We will not deliver within the resources available.
3. We will fail to deliver within the timeframe needed.
4. We will not deliver a product the market needs or wants. This is often the most underestimated risk.

1. Poor Quality

Time and time again we hear about large project failures in the media. Take the New Zealand Ministry of Education’s payroll system Novopay. Delivered $12 million over budget (a more than 100% cost overrun) and at a universally agreed level of poor quality, Novopay’s problems and lack of success have remained in the media for years. The government had to spend $45 million fixing the system and supporting schools. In 2018 it was reported that $26 million would be spent to extend the life of the system.

Poor quality is a root cause of many failed projects. It creates security risks. It destroys team productivity as more and more time is eaten up with finding and fixing defects. The teams that work on these systems often have one defining trait — they are terrified of touching the code base. They know that it is fragile but have no idea of where or how badly.

2. Too Expensive

The second risk is that the project will consume all available resource and still not be in a complete state.

The KPMG research found that only 29% of New Zealand projects come in on budget.

Examples abound. For example, at the time of writing it has just been announced that the plug has been pulled on the National Oracle System for New Zealand’s health boards. The project had spent $90 million without achieving its objectives and was shut down when it asked for a further $23 million to complete the work.

3. Delayed Delivery

The third risk is that the project may not be delivered in time. Many projects are extremely time-sensitive, and missing deadlines means lost revenue, lost market share and sometimes penalties.

Poor quality is a common cause of missed delivery deadlines. This problem is exacerbated by late integration, meaning that issues of quality are not discovered until very late in the project.

4. Perfectly Executed Failure

The fourth risk is that businesses may hit their deadlines, make their budgets and even deliver the necessary quality only to find that they have delivered a product nobody wants. Eric Ries describes it as “achieving failure”.

“We spend a lot of time planning. We even make contingency plans for what to do if the main plan goes wrong. But what if the plan goes right, and we still fail?”

To reduce the likelihood of these risks impacting our projects, we need to stop and ask ourselves what we need to do differently. How do we adapt our management approach to ensure we deliver the right value to our organisation and our customers?

You can sum up the risks as challenges to these four success factors:

Agile software development has a number of ways to reduce these four risks. The most powerful of these approaches are:

Together this gives you an Agile project risk management model. This model shows how different Agile approaches mitigate different risks, with each approach primarily affecting one of the areas identified, as well as influencing the other areas.

There are various tools for managing the common risks. Taken together, these tools greatly increase our chances of successfully delivering projects for our organisations.

The tools enable us to prioritise the continual, incremental delivery of working software. By prioritising the delivery of working software we are able to constantly inspect the quality, functionality and desirability of the software.

Like tasting food while you are cooking, we taste at every stage of the project and adjust the ingredients and seasoning as needed to ensure a flavourful and well-balanced dish.

Effective Prioritisation

Rigorously prioritising work reduces the risk of delivering software of low value while ensuring that costs are controlled by only working on what is important to our organisation and customers.

When working with Agile methodologies such as Scrum and Kanban we focus on prioritisation. Focusing on the highest value work is a key Agile project risk management technique. It avoids time and energy being diverted into low value work. This lets us deliver value to our customers much earlier than in traditional Waterfall projects.

Using Agile delivery, project work is strongly prioritised as the assumption is that all functionality will and must be delivered in small batches. In Agile projects, re-prioritisation happens continuously in the backlog of work as more information is discovered about the project. In contrast, with staged project delivery methods, priorities are set once at the start of the project, if at all, and are often based on imagined future needs and dependencies.

Related: Get practical techniques for reducing risk with prioritisation

Increasing Transparency

Increasing transparency reduces the risk of producing work of poor quality and helps to ensure that the project is delivering value.

Transparency is at the heart of Agile project risk management. If we do not have a full and accurate view of the status of the project, the business priorities, the resource needed to deliver and the quality of the output, we cannot manage risk in the project.

Consider the graph below. We can see that risk remains high in a Waterfall project right until the majority of the functionality is delivered. Contrast this with the Agile project shown on the graph, where risk drops quickly and significantly as we start to deliver working, tested and deployable software.

During an Agile project we can shift the focus at any stage. Should we discover that our users need feature X instead of feature Y we can re-plan and re-prioritise without any penalty to our overall timeline.

Agile works to make projects more transparent in a number of different ways. Examples include regular retrospectives, Kanban boards, Scrum boards and other information radiators that make visible the work of the team and the progress being made.

Related: Get practical techniques for reducing risk with transparency

Reducing Batch Size

Reducing batch size reduces the risk of cost and time overruns while also increasing quality.

Core to reducing the variability in our projects is reducing the size of the batches we work in. Agile projects constantly work to reduce batch size in every part of the project.

Reducing batch size is important for managing cost on projects for three reasons:

1. It enables us to be more productive.
2. It reduces the variability in the work.
3. It enables us to inspect the output of our work at greater frequency.

Tools for managing batch size in Agile include:

• Splitting stories into the smallest increment of value
• Working on vertical slices of a system
• Continuous integration
• Increasing the frequency of deployment

Related: How to reduce batch size in Agile software development

Limiting Work In Progress

Decreasing WIP reduces the risk of missing deadlines and also increases the quality.

Limiting work in progress (WIP) is an effective Agile project risk management technique for ensuring your ability to deliver quality work on time.

We can see in the graph below (based on Gerald M. Weinberg’s Quality Software Management: Systems Thinking) that as we have more tasks in progress at any one time, productivity starts to fall to zero as we spend more time context switching.

With many of the Agile methodologies there is a focus on managing and reducing work in progress. Scrum does this using timeboxes. High-performing teams actively work together to reduce their work in progress by ensuring that each story is fully completed, tested and ready to deploy before moving on to the next story.

In addition to timeboxes there are a number of other tools for limiting work in progress, including:

• Explicit WIP limits in Kanban stages
• Continuous integration
• Test and behaviour driven development
• Protecting the team from outside requests

Related: How to manage project risk by limiting work in progress

Reflecting on the traditional project management methodologies used in software development, it is easy for us to conclude that what appears concrete and real is merely wishful thinking. The scope, resource needed and cost are often portrayed as concrete and known, having been deduced through experience or wisdom.

However, we impose on the team what we wish to happen in terms of scope, time, quality and cost without actually giving them the tools or mandate to actively manage any of these variables. The team is being subjected to wishful thinking and is too often punished if they do not achieve these goals.

In contrast, Agile inspects the output of the team and adjusts expectations, resources and approaches based on evidence. The team is given the mandate to maintain quality and make decisions about how this is achieved. The business communicates its needs and the team determines how best to achieve this outcome with the resources available.

Rather than relying on wishful thinking, Agile provides pragmatic and tested ways to improve the success of our projects. Agile organisations across the world are applying these techniques to deliver better software more quickly.

The approaches mentioned in this guide are a few of these concepts and the application of these will vary across different teams, projects and organisations.

We hope that this has helped you to identify opportunities to reduce and manage risk within your teams and organisation.

The Agile risk management model describes the relationship between Agile approaches and the risks common to software development projects.

For organisations, it demonstrates how Agile actively mitigates risk in ways that traditional methodologies do not. It gives you a decision-making tool for choosing your project management methodology.

For teams, it clarifies how different but interrelated Agile approaches and tools address the risks you face on projects everyday. It gives you tools for planning how you’ll manage and mitigate risk.