An Agile Risk Management Framework

I love working with smart people. They make it easy and fun to solve nasty problems. Tony Grout is one such person. He is a really deep thinker on the subject of theory of constraints. One of the problems faced by many large organisations is that they have a prescriptive software development life cycle or SDLC for short. The organisation insists that all IT Projects follow the SDLC. The SDLC is normally very binary in nature. If your project is of type XYZ, then you need to do ABC. This poses a problem for Agile development which doesn’t follow the same philosophy. Rather than one size fits all, Agile development adapt to the risk profile of the context they are operating in. Often without realising it, most Agile development follows Alistair Cockburn’s Crystal methodology.

At Lean Kanban London Day, Tony Grout and I presented our view on the Agile Organisation. (Hat tip to SAFE).


A key part of that organisation for any Large IT Organisations is the Governance Function. This consists of four key parts (A metaphor of speed restrictions for drivers is provided in brackets to aid understanding):

  1. An IT investment risk management framework. (The law stating 30 mph in residential areas. 20 mph is areas with people at heightened risk such as schools and hospitals)
  2. A policing* function to ensure that all investments operate within the framework. (Speed cameras and traffic police)
  3. A governance function to ensure the risk management framework evolves appropriately according to context. This function also acts to help interpret the framework in a particular context. (Courts and law making bodies)
  4. The responsibilities of ordinary citizens. (Driving tests).

Separate to the governance function is the capabilities that allow development teams to deliver IT investments. The problem with many SDLCs is that they combine the risk management framework with the capabilities needed to deliver them. The IT investment risk management framework should be the smallest set of constraints that the organisation imposes on the development and change organisation to ensure that the risks associated with the IT investment are managed appropriately. The constraints should be helpful and instructive rather than arbitrary. The constraints should give comfort to investors that their investment will be protected against the three categories** of risk, namely:

  1. Delivery Risk – Will the functionality be delivered.
  2. Business Case Risk – The IT Investment delivering the stated return.
  3. Existing Business Model Risk – Will the IT Investment damage the existing business model.

Tony and I categorised the risk management framework into the following attributes of an Agile development. If an IT Investment does not satisfy these criteria, it should be considered NOT Agile and thus managed under the existing SDLC. These categories are:


We even use them as part of our training.

LKD Manifesto

The policing function is particularly important for an Agile IT Investment Risk Management Framework as context is so important to the approach, and it is easy to game the rules. The policing function should work closely with the organisation’s Agile Coaches to help development teams learn to operate within the rules. This policing function should never be performed by Agile Coaches as it would destroy the relationship between the coaches and the development teams.

The IT Investment Risk Framework specifies the impact of each risk category on each part of the organisation.


Our next posts will expand on the framework, starting with the detail for “Delivering Value” for the “Exec”.

* By policing function, I am referring to one like an idealised 1950s Britain where the police are considered public servants (Dixon of Dock Green) rather than some countries where they are considered a domestic army to suppress the people.

** These three risks were first articulated by Steve Freeman and myself in an article published in the Agile Alliance’s Agile Times in 2005(Date ?).

About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

4 responses to “An Agile Risk Management Framework

  • Five Blogs – 1 June 2016 – 5blogs

    […] An Agile Risk Management Framework Written by: Chris Matts […]

  • KentMcDonald

    Hi Chris, thanks for sharing. The metaphor of speed restrictions is helpful in some sense (I can certainly related to it since I tend to run afoul of such governance frequently).

    It would also be helpful to see a bit more information on an actual example. That said I realize that everyones mileage may vary, but seeing one way this has been implemented could be very instructive.

  • deano14

    Chris this is a really useful post. It helps frame the problem. One strand that you often see in large oranisation is the role of the drivng instructor. Where teams need to learn to drive before they take their test.
    In otherwords, there is the need to demonstrating how to do the basics, so that they can then operate within the risk framework. Is this justification for giving people a way to operate as a starting point? When they are confident and capable… they can take the ‘L’ plates off?

  • mohsina

    very usefull article i have learnt a lot from this article in risk managements

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: