Agile Risk Management: A Disciplined Approach

Costa Concordia cruise ship that ran aground

We’ve recently been asked how risk management is addressed on agile teams. This is an easy question to answer because risk management strategies are built right into the Disciplined Agile Delivery (DAD) framework.

Let’s start with two definitions. First, a risk is an exposure to a potentially negative outcome. Risks come about from uncertainty. Second, risk management is the identification, exploration, and mitigation of risks. Risk management should be part of both your team management efforts, even on self-organizing agile teams, as well as part of your organizations governance efforts.

Regardless of your delivery paradigm, there are several common categories of risks faced by IT delivery teams:

  • Business risk. This includes significant shifts in requirements due changing business priorities, often due to realization new market opportunities, in reaction to moves made by competitors, or because you are opening completely new market opportunities. Another common risk is an overly optimistic/aggressive schedule which motivates your team to take unfortunate shortcuts. A third type of business risk is a misaligned budget: either there isn’t sufficient funding to do the job effectively (e.g. there’s no travel budget for a geographically distributed team, there’s no funding for coaching on a team new to agile, there’s no funding for training, and so on) or there is far too much funding available and the team is motivated to invest it in wasteful activities.
  • Technical risk. IT teams face technical risks as the result of combining technologies in new ways, evolving technology platforms, new technologies, and lack of experience within the team in these situations.
  • Operational risk. This category of risk pertains to production-oriented issues surrounding the support and operation of a solution. Will your solution work within the existing organizational ecosystem? Does your operations team have the skills and resources to run your solution? Does your support/help desk team have the experience and knowledge required?
  • Process risk. As the DAD framework clearly shows, every technique has advantages, disadvantages, and specific situations where the technique makes sense. The implication is that there are risks taken on when you apply a technique outside of its range of applicability or your comfort zone.
  • Organizational risk. IT teams face organizational risks such as dysfunctional politics, competing visions, challenges pertaining to your agile transformation challenges, reorganizations, and many others.

Recognizing that IT delivery teams must deal with risks on a regular basis the DAD framework builds in several agile risk management strategies:

  • Continuous engineering practices.  This is a collection of practices with very short feedback cycles, thereby enabling you to adjust course quickly. These practices include behavior driven development (BDD), test-driven development (TDD), continuous integration (CI), continuous deployment (CD), and many others.  All of these practices require discipline and skill to adopt.  Although these practices are technical in nature, in practice they mostly reduce business risk through shortening the cycle between a stakeholder having an initial idea and the team providing a solution which reflects that idea.
  • Agile architecture practices.  The DAD framework suggests a collection of continuous architecture strategies throughout the entire lifecycle.  These include, but are not limited to, identifying an initial technical strategy, proving the architecture early in construction, deferring architecture and design decisions to the most appropriate moment, architecture spikes, just in time (JIT) model storming, and many others.  These practices reduce technical risk.
  • Risk-value lifecycle.  The DAD framework supports several lifecycles, and hence several work prioritization strategies.  One such strategy is the Unified Process (UP)’s risk-value approach where both risk and value are considered when prioritizing work items.  The end result is that work items with higher technical risk are implemented early in the lifecycle, enabling disciplined agile teams to mitigate technical risk early in the effort.  DAD teams then follow Scrum’s value-driven approach where the work is prioritized based on its business value to the organization, which is effective at addressing some forms of business risk.  The risk-value prioritization approach results in a lower overall risk profile than just the value-driven lifecycle of Scrum.  DAD also supports lean and continuous delivery versions of the lifecycle which expand upon the risk-value strategy to consider other factors such as required release dates and team health considerations.
  • An explicit Inception phase.  The fundamental purpose of the Inception phase is to help your team get going in the right direction.  Executed properly, the Inception phase helps you to reduce business risk by coming to stakeholder agreement regarding the team’s strategy, technical risk by exploring a viable technical strategy, and operational risk through planning with production-staff from the very beginning.
  • Risk-based, light-weight milestones.  The DAD lifecycles include explicit milestones as part of DAD’s overall governance strategy.  These milestones motivate teams to address common issues such as formulating an agreed-to vision early in the effort (business risk), proving the architecture early (technical risk), regularly considering the viability of the effort (business risk), ensuring the team has produced sufficient functionality to justify deployment (business risk), ensuring the solution is production ready (operational risk), and ensuring that the stakeholders are delighted with the result (business risk, organizational risk).
  • Development intelligence.  One of the governance strategies that the DAD process framework promotes is development intelligence (DI) where a team/project dashboard is populated with metrics generated automatically by the tools the team is using.  This provides real-time insight for the team to organize itself and potentially improve its approach.  It also provides insight into your organization’s governance effort, supplying real-time data which can enable senior management to make better decisions and thereby better support your agile teams.  Development intelligence, and it’s extension IT intelligence which addresses the entire IT portfolio and processes, helps you to reduce process risk and to a lesser extent organizational risk.
  • DevOps principles and practices. DAD weaves DevOps strategies through the entire framework.  This strategies are: Including operations and support staff as explicit stakeholders who work closely with the team; the lifecycle explicitly depicts production/operations; DevOps-oriented milestones (Production Ready and Delighted Stakeholders) are included as part of the governance strategy; development practices such as instrumenting solutions for operational monitoring, continuous deployment, and installation testing (to name a few); and management practices such as deployment planning. The strategies help to reduce both operational and organizational risks.
  • Sophisticated go-forward decision points.  One of the business risk management strategies promoted by Scrum and RUP is to make a “go/no-go” decision at the end of each sprint/iteration.   DAD takes this strategy further by recognizing that you have several options to consider – your team can continue with its current approach (go), it can stop (no-go), it can decide to change direction (pivot), or it can decide to experiment (run a split test).  The two new options are adopted from Lean Startup. DAD’s lean and continuous delivery lifecycles promote the idea that you make these go forward decisions when you need to, that you don’t need to wait until the end of an iteration to do so.
  • Risk-oriented process goals.  The DAD framework promotes a non-prescriptive, process goal-driven approach.  Two of these process goals are risk-oriented: Identify Risks and Address Risks.  The goal diagrams for them are presented below in Figures 1 and 2 respectively.  As you can see both of these goals depict a range of risk management techniques that can be applied by agile delivery teams.

Figure 1. Risk identification starts early on.

Identify Risks

Figure 2. Risks are addressed throughout the lifecycle.

Goal - General - Address Risk


  • IT risk management is built in. IT-level risk management is built into the IT Governance process blade.  Although a risk may be small for a single team, when that same risk is taken by multiple teams in parallel in aggregate the risk may be more than your organization should take on.  Hence your risk management efforts at the delivery team level must be monitored regularly and aggregate risks mitigated appropriately. The process goal diagram for IT governance is shown below in Figure 3.

Figure 3. IT-risk management is an aspect of IT Governance.

Disciplined Agile IT Governance


Risk management isn’t explicitly built into first generation agile methodologies like Scrum or XP, although a handful of implicit risk mitigation techniques are.  As a result you still need to develop a risk management strategy for yourself when you limit your team to these sorts of agile methods.  The DAD process decision framework, on the other hand, has built risk management strategies into the framework in a lightweight and comprehensive manner.  From the point of view of process risk, having such guidance built into your process is a low-risk and desirable approach.  For further reading about risk management, we highly suggest the list of references maintained by Glen B. Alleman.

3 thoughts on “Agile Risk Management: A Disciplined Approach

  1. Jonathan Ward

    I think your terminology misses something. When implementing a change, new software or process, the business will alter the way it operates. Most US businesses are engage in risk management activities. Risk Management is a field of business management that deals with identifying and preventing possible damaging outcomes within an organisation. To mitigate these risks process and organisational controls are put in place. When a project is envisaged it is essential that the potential impact on the Business Risk level is assessed or if existing controls are nullified or if additional controls are needed. Like non-functional requirements this Business Risk assessment generates requirements that the project team must fulfill or ensure that another part of the organisation provides the necessary. I think you should re-term Business Risks as Delivery Risks.

    1. Scott Ambler Post author

      Jonathan, you make an interesting point. However, I’m not convinced that Delivery Risk is the right term either as other risks, technical risk for example, could also fall under that umbrella.

      Terminology is always a challenging issue. No matter what set of terms you choose someone will always come along with a good reason why other terms would be better. I’ve seen team go in endless cycles on this sort of thing.


Leave a Reply

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