Reduce Your Risk Of Failure

This content is syndicated from by Kelly Waters. To view the original post in full, click here.

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 3x3 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

Leave a Reply

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

four × 3 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”



To explore how we can help you, please get in touch