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.

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 ?).