A spider web has several external risks.

A spider web has several external risks.



Making sure external risks are addressed in an Agile effort, or any effort for that matter begins with making sure that at least a basic risk management approach is in place. If a basic risk management approach is in place we can integrate the concept of external risks.  Everyone involved should understand the basics of the risk management process being leveraged on the effort.  All risk management processes need to identify who is responsible and how the process fits into the value delivery flow.  Specifically, incorporating the idea of external risks into the process is typically more urgent as the scale and duration of the effort increases if for no other reason than longer efforts are exposed to the trials and tribulations of the outside world longer than small efforts.  The size of the effort affects two main variables used to scale  Agile risk management.  The larger the effort the greater the need for the people involved with the effort to define who is responsible for risk management and how much process is needed to keep things organized.   The size of the effort, while a continuum, will be represented by small efforts (one team and a few iterations or sprints) and large efforts (over 75 participants with at least 6 iterations or sprints) for illustration.  

Responsibility. A responsibility defines who will ensure that risks are managed in an effort.

  • In small efforts using Scrum or Extreme Programming (XP), the risk is collaboratively managed by the whole team.  Scrum and XP build team-level risk management directly into how work is done; allowing the responsibility for risks to be a bit more nebulous than in large or riskier projects.  At a team level, the process of self-organization is often enough to facilitate the process. When self-organization is not enough to generate a collective responsibility for risk management the introspective feedback generated in iteration or sprint retrospectives should provide the impetus to get things back on track. The Scrum master should help to identify and focus the team collectively managing risk. Collective risk management can be effective for identifying external risk by leveraging the diversity of the team when coupled with a process that prompts the team to look outward.
  • Larger efforts require more formality in identifying who is responsible for championing the risk management process.  For example, in SAFe, the release train engineer (RTE) is responsible for making sure the program increment planning process (which includes the identification and ROAM’ing of risks) occurs and is completed.  The release train engineer also acts as the focal point to ensure that the backlog, including ROAM’ed risks, is groomed and prioritized.   The size/scale of the effort requires someone to champion risk management or it could easily be uncoordinated. The RTE acts as a connector between all of the teams through the Scrum-of-Scrums (SoS).  Through the SoS and a big picture view of the effort, the RTE can be instrumental for identifying and managing external risks.

Process.  The process defines how risk management practices are built into the flow of how value is delivered.  

  • Small Agile efforts build risk management into the process (lean process) easily by adopting Scrum or XP.  However, most small efforts tend to ignore external risks. Therefore, the process needs to build in some form of awareness building for external risks.  For example, small efforts often only need a checklist of common external risks (common being relative to the type of work being done) that can be referenced as a memory jogger when building and grooming their backlog and/or during iteration planning.  For small efforts, the time horizon is short enough that aggressive risk management approaches are not needed.  The goal in small efforts is to ensure that a conversation about both internal and external risks are happening on a consistent basis.
  • Large efforts require a more explicit process to identify and manage external risks.  One very powerful method is a future telling session (we will examine this technique in detail in the near future) in which participants develop a vision of the overall effort and the journey toward that effort.  During the session, the facilitator of the session challenges the storytellers to identify what might endanger or derail their effort (risks).  The risks then can be ROAM’ed (if using SAFe).  Tools and techniques to shift the focus from just internal risks to both internal and external risks are needed because the potential for outside forces to impact the effort are significantly higher.

In small efforts using Scrum or XP a risk management is built in.  Injecting the idea of external risks requires a less overt hand.  Techniques like checklists can be used as a memory prompt. Many (not all) of these efforts are over and done before anything significant can get in the way.  Larger efforts are not that lucky.  Someone needs to champion risk management and external risks need to be explicitly discussed and the horizon needs to be constantly scanned!  

Current Risk Thread:
External and Internal Risks
Incorporating the Idea of External Risk into Agile Efforts (Current)
Risk Tolerance
Future Telling as a Risk Management Tool

Advertisements