reduce your risk of failureThe key principles of agile software development help to mitigate many of the common reasons for project failure.

In particular, the incremental approach and active user involvement guard against one of the biggest risks. The risk of building a software product that doesn’t meet expectations. The risk of building the wrong product.

But how does agile software development help you to manage risks that fall outside the development process? The risks that aren’t inherently reduced by an agile approach.

Here I take a look at how you could incorporate a more traditional approach to risk management, within a project that’s using an agile approach…

In a more traditional PRINCE2-based project, you would keep a risk log. Typically a risk log would include the following information:

  • description of the risk
  • date raised
  • likelihood – description of its likelihood and rating (1 unlikely, 2 possible, 3 likely)
  • impact – description of the impact and rating (1 low, 2 medium, 3 high)
  • mitigation – what could or should be done to reduce the likelihood of the risk?
  • contingency – what will we do if the risk becomes an issue? What should we be doing to plan for it’s eventuality, particularly if it’s likely
  • actions (with dates and owners)
  • last updated – when the entry in the risk log was last updated and by who

You can keep a risk log in agile projects too. Of course. There are no rules in agile which say you must not use any other management approaches or artifacts in conjunction with an agile approach.

But how do you make something like a risk log more akin to agile principles? And how do we integrate this kind of risk management within the iterative cycles of agile development? Here are some suggestions…

  1. Make it visible. Put it on the wall for all to see. For the team, project manager, product owner, etc to see every day in the daily stand-up meeting.
  2. Make it collaborative. Allow anyone to add a new risk or add comments on an existing risk any time they want.
  3. Make it visual. Put the likelihood and impact in a 3×3 grid, so likely risks with high impact are top right (in red) and unlikely risks with low impact are bottom left (in green). Each risk then gets a score of 1-9, i.e. likelihood*impact.
  4. Make it part of the process. In Sprint (iteration) planning – as well as asking what went well, what didn’t go so well, what would we do differently in the next iteration – also ask what could prevent us from meeting our objectives? For the Sprint and for the project as a whole. Facilitate the team’s thought process to actively identify risks. Add them to the risk log on the wall.
  5. Include it in the product backlog (‘feature’ list). If it’s appropriate to do something to mitigate a risk and reduce its likelihood, or to prepare contingency for the risk, add the actions to the Product Backlog for the project and prioritise them along with the features. The Product Owner is then taking business responsibility for the risk and its priority relative to features of the product. If a risk occurs before the mitigating actions are reached, this was a knowing commercial judgement about its priority and not a failing of the team to identify or highlight the risk.
  6. Review it daily. In the daily stand-up meetings – as well as asking what have you done since the last meeting, what will you do before the next meeting, and if there anything holding up your progress – also ask each team member if there’s anything that could prevent them from meeting their goals. This will encourage a little proactive thought, not just reactive when progress is blocked.
  7. Make it the team’s responsibility (to identify and highlight risks). By asking the team to identify risks during planning meetings, and within each iteration. By asking the team to rate the likelihood and impact. By asking the team what could be done to reduce a risk’s likelihood. By asking the team what we would do if the risk materialises. However the priority of a risk is still a business decision. It’s up to the Product Owner to decide on the priority of a risk, in relation to other activities on the backlog.

In other words, on major projects particularly, make risk management part of your everyday business.


See also:
Why most IT projects fail. And how agile principles help
A sad indictment of the software development industry
10 Key Principles of Agile Software Development
10 Key Principles – PowerPoint presentation

Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
145 City Rd
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at