Agile 101

Project Management, Digital Publishing and Agile Software Development

Archive for the ‘Agile Risk Management’ Category

12 Principles of Risk Management (PMBOK – with an Agile slant)

Posted by Tara Hamilton-Whitaker on July 28, 2009

12 Principles of Agile Risk Management (PMBOK with an Agile Slant)The Project Management Body of Knowledge (“PMBOK”) describes 12 Principles of Risk Management.  I’ve taken the headings and summarised the main messages from an Agile perspective.

1) Organisational Context

There’s no ‘one-size-fits-all’ when it comes to Risk Management. Each organisation will be affected by different Political, Economic, Societal, Technological, Legal and Environmental factors (“PESTLE“).

It’s also worth pointing out (the obvious) that each organisation will have different internal cultures, communication channels, levels of agile-adoption and existing risk management processes.

2) Stakeholder Involvement

Involve your stakeholders wherever possible.  Keep them informed and understand the role they can/could play at each stage in the Risk Management process > Identify, Assess, Respond, Review.

3) Organisational Objectives

When assessing and responding to a risk, be sure to keep the overal organisational objectives in mind – see the bigger picture.

When considering a Task-level risk, look at the role it plays towards delivering a User Story. If you’re concerned about a User Story, consider the impact it has on delivering your Sprint Objective or the relevant Theme.  If you’re concerned about a particular Theme, then look at the relevant Epic or the Programme of works.

Keep things in perspective and don’t lose sight of your end-goal.

4) Management of Risk Approach (N/A)

This particular principle is less applicable as it refers specifically to the PMBOK Risk Management processes, however the message basically stresses the importance of following best practice guidelines and learning from the mistakes of others.

5) Reporting

Keep people informed – ensure transparency and visibility. Communication is key!

6) Roles & Responsibilities

Make sure that everyone understands the role they play at each stage of the Risk Management Life cycle i.e. > Identify, Assess, Respond, Review.  Ensure that all bases are covered by someone.

7) Support Structure

Ensure that everyone understands how risk is managed through the Risk Management Life cycle and who to go to if they have any questions.

For example:

  • How are risks identified (e.g. via Daily Scrum)
  • How and when are risks escalated?
  • Where and in what format are risks documented?
  • How and when are risks reviewed (e.g. Retrospective)
  • etc.

8) Early Warning Indicators

Give yourself the best chance of forecasting/anticipating the transition of a Risk to an active Issue. Ensure that everyone is communicating and that any potential issues are highlighted in the Daily Scrum.

It’s also important to know how you should react in the event a risk does or is about to be realised e.g. who needs to know and how will you inform them – in the Daily Scrum also? Or, maybe in the Scrum of Scrums? Or, maybe you’ll just walk over and tell them.

9) Review Cycle

Make sure that your Risk Board is visible and that you’re regularly reviewing it – you could do this via the Retrospective and as an extension to the Daily Scrum by adding a 4th question:

  1. What did you do since the last sprint?
  2. What will do you today?
  3. Is there anything blocking you at the moment?
  4. Any changes to the risks board?

10) Overcoming Barriers to the Management of Risk

Ensure you’re doing everything you can to give you the best chance of successfully managing risk.

Some common barriers include:

  • Established roles, responsibilities, accountability and ownership.
  • An appropriate budget for embedding approach and carrying out activities.
  • Adequate and accessible training, tools and techniques.
  • Risk management orientation, induction and training processes.
  • Regular assessment of Management of Risk approach (including all of the above issues).

11) Supportive Culture

Make sure that everyone on the team feels comfortable raising, discussing and managing risks.

12) Continual Improvement

Use the Retrospective to review the way you manage risk and to assess ongoing risks. Learn from your mistakes.


  Subscribe to the Agile101 RSS to be notified when I upload new Articles Templates and Tips!


Related Articles:

Posted in Agile Risk Management | Tagged: , | Leave a Comment »

Agile Risk Management – Identifying Risks (1 of 4)

Posted by Tara Hamilton-Whitaker on July 27, 2009

Agile Risk Management Process - Identifying the RiskRisk identification is the first stage in the Agile Risk Management process. This stage is followed by Risk AssessmentRisk Response and Risk Review.

A Risk is an uncertain event that will impact your chosen path should it be realised. Risks are events that are not currently affecting you – they haven’t happened yet.  Once a risk is realised, it becomes an Issue.

In Agile environments, the team shares responsibility for identifying risks that might affect a sprint, project or programme of development.

The Scrum meetings provide a strong forum for identifying risks on a daily basis.  Also, as most meetings take place before any commitments are made, the Product Manager and the team are able to mitigate/remove Scope-related risks before they’re allowed to enter a sprint.

Regardless of the forum, all risks end up either on a team Risk Board or on the programme Epic Board.

Requirements Workshop

The team and the Product Manager discuss new ideas, their viability and a rough idea of the effort required to deliver them (E.g. t-shirt size estimation). This conversation allows the Product Manager to re-consider and/or adjust requirements in a way that maximises value and minimises risk/uncertainty. Read more about Requirements Workshops.

Planning Poker

In this session, the team estimate the relative size of each User Story. Studies show that uncertainty increases as the size of a User Story increases.  This is yet another opportunity for a Product Manager and a team to reduce risk by rejecting User Stories over a certain size – they’re either broken down into smaller stories or they are forced to wait until a later sprint i.e. once they’ve been investigated further. Read more about Planning Poker

Sprint Planning

Sprint Planning is yet another opportunity for the team to identify, assess and respond to Risk. They only accept work they feel confident about delivering – they will work with the Product Manager to maximise output in a way that reduces risk of failure. Read more about Sprint Planning

The Daily Scrum

Once the sprint has commenced, the Daily Scrum becomes the main forum for raising Risks and Issues. We ask the question “Is anything blocking you or likely to block you from progressing as planned?”

We add highlighted risks to the Risk Board and catch up with the individual after the Daily Scrum to gather more details and agree a Response plan.

Any non-team members may raise Risks via the Scrum Master after the Daily Scrum when we break-out into smaller discussion groups. Read more about The Daily Scrum

Sprint Review

The Sprint Review is yet another forum where risks can be discussed. This session also provides an opportunity to highlight successful mitigation/evasion activities – it’s good to keep your stakeholders informed of what’s going on.  It’s worth noting that the Product Manager will under normal circumstances be liaising with Stakeholders and the Product Owner on a daily basis, so communication and awareness should be strong. Read more about Sprint Reviews

Sprint Retrospective

Although the Retrospective discussions will focus primarily on the idea of continual improvement, risks do inevitably become unveiled at this session.  This happens naturally as we review re-occurring issues, discuss weaknesses and disruptions.

The key questions answered at a retrospective are:

  1. What went well last sprint? < e.g. this could be the successful handling of a risk
  2. What didn’t go so well last sprint? < e.g. this could be the realisation of a risk or the re-occurrence of an issue
  3. What will we do differently next sprint? < e.g. this could include risk mitigation/response activities

See a great presentation about Retrospectives by the authors of Agile Retrospectives –  Making Good Teams Great.

Scrum of Scrums

In this session, we review project-level progress, risks and issues. The session is attended by the Scrum Master(s), Product Manager and Product Owner(s). Read more about Scrum of Scrums

Programme Planning Meeting

Although this is not a traditional Scrum Meeting, we use this session to review progress at a Programme level i.e. multiple projects plus Business As Usual activities. This meeting takes place in front of the Epic Board – a tool we use to track delivery, risks and issues at a programme level.

This session is attended by Product Managers, the Programme Manager and a Central Project Manager i.e. an individual responsible for the day-to-day management of cross-team delivery and coordination.

The next stage in the Agile Risk Management Process is Risk Assessment.

Related Articles:

Posted in Agile Risk Management | Tagged: , | 1 Comment »

Agile Risk Management – Assessing Risks (2 of 4)

Posted by Tara Hamilton-Whitaker on July 27, 2009

risk-management-assessRisk Assessment is the second stage in the Agile Risk Management process. This stage is preceeded by Risk Identification, and followed by Risk Response and Risk Review.

A Risk is an uncertain event that will impact your chosen path should it be realised. Risks are events that are not currently affecting you – they haven’t happened yet.  Once a risk is realised, it becomes an Issue.

Risks may be attributed to Political, Environmental, Societal, Technological, Legal or Economic (”PESTLE“) factors.

Mike Cottmeyer has described an alternative way to categorise risk:

We use two measures to grade a risk:

  1. The probability/likelihood of it being realised
  2. The impact it will have if it is realised

As described in my post Agile Risk Management – The difference between Risks and Issues, a simple way of classifying a risk is through the use of a grading scale e.g. 1-5 or a Fibonacci sequence, with 1 being low impact/likelihood and 5+ being high impact/likelihood.

For example:

  • A User Story is severely underestimated in the first sprAint, compromising the team’s ability to deliver their commitments (1,5)
  • A User Story is severely underestimated in sprint 10, compromising the team’s ability to deliver their commitments (5,1)
Risk Matrix - Impact vs. Likelihood

Risk Matrix - Impact vs. Likelihood

In the first example, the Impact is low and the Likelihood is high.  Most teams take a few sprints to find their pace. Business expectations are managed to this effect and there’s a strong chance that the schedule has been designed to assume a high degree of uncertainty during this time.

In the second example, the Impact is high and the Likelihood is low. We would not expect an established team to severely underestimate a User Story. As such, the impact is likely to be much higher.

This Impact vs. Likelihood assessment is done quickly – it’s not an exact science, we just want to get a sense of scale, urgency and priority so we can determine the most appropriate Risk Response.

The results of this exercise are added to a whiteboard. Different teams tend to represent Risks differently (some as post it tags on stories, others using a risk matrix) – there’s no wrong way to do it so long as the risks are visible and regularly referred to by the team.

This board should be reviewed regularly as part of the Daily Scrum and/or as part of the end-of-sprint Retrospective.

The next step in this process is Risk Response.

  Subscribe to the Agile101 RSS to be notified when I upload new Articles Templates and Tips!

Related Articles:

Posted in Agile Risk Management, Project Management | Tagged: , | Leave a Comment »