Risk Management Is How Adults Manage Projects: Agile is Not Risk Management (Alone)

Risk Management is How Adults Manage Projects - Tim Lister

Here's a formal definition of Risk Management.

Risk management is an endeavor that begins with requirements formulation and assessment, includes the planning and conducting of a technical risk reduction phase if needed, and strongly influences the structure of the development and test activities. Active risk management requires investment based on identification of where to best deploy scarce resources for the greatest impact on the program’s risk profile. PMs and staff should shape and control risk, not just observe progress and react to risks that are realized. Anticipating possible adverse events, evaluating probabilities of occurrence, understanding cost and schedule impacts, and deciding to take cost effective steps ahead of time to limit their impact if they occur is the essence of effective risk management. Risk management should occur throughout the lifecycle of the program and strategies should be adjusted as the risk profile changes. 

Managing in the presence of uncertainty and the resulting risk, means making estimates of the outcomes that will appear in the future from the decisions made today, in the presence of naturally occurring variances, and probabilistic events during the period over which the decision is applicable. Without these estimates, there is no means of assessing a decision for its effectiveness in keeping the project on track for success.

There is a connection between uncertainty and risk.

• Uncertainty is present when probabilities cannot be quantified in a rigorous or valid manner, but can be described as intervals within a probability distribution function (PDF).
• Risk is present when the uncertainty of the outcome can be quantified in terms of probabilities or a range of possible values.

This distinction is important for modeling the future performance of cost, schedule, and technical outcomes of a project in the presence of reducible and irreducible risk.

Uncertainties that can be reduced with more knowledge are called – Epistemic or Reducible.‡

Epistemic (subjective or probabilistic) uncertainties are event based probabilities, knowledge-based, and are reducible by further gathering of knowledge. Epistemic uncertainty pertains to the degree of knowledge about models and their parameters.

This term comes from the Greek episteme (knowledge). Epistemic uncertainties,

• Are Event based uncertainties, where there is a probability of something happening that will unfavorably impact the project.
• Are described by a probability that something will happen in the future.
• Can state this probability of the event, and do something about reducing this probability of occurrence.

Uncertainties that cannot be reduced with knowledge are called - Aleatory or Irreducible†

Aleatory uncertainties pertain to stochastic (non-deterministic) events, the outcome of which is described using a probability distribution function(PDF). The term aleatory come from the Latin alea. For example in a game of chance stochastic variability's are the natural randomness of the process and are characterized by a probability density function (PDF) for their range and frequency. Since these variability's are natural they are therefore irreducible.

• These are Naturally occurring Variances in the underlying processes of the program.
• These are variances in work duration, cost, technical performance.
• We can state the probability range of these variances within the Probability Distribution Function.

When it is suggested projects can be managed in the absence of estimating the impact of any decisions, probabilistic events, or underlying statistical processes - think about Lister's quote and read his presentation - and proceed at your own risk.

In a recent post Top 5 Ways Agile Mitigates Risk, suggests Agile is the same as Risk Management. While the items listed there are good project management, the term Risk Management for projects means something else beyond the agile concepts in the post. 

Let's look at each of these suggestion that Agile is Risk Management. First let's look at the processes of risk management and what they entails in practice.

These processes have specific activities and relationships:

• Risk Identification - Before risks can be managed, they must be identified. Identification surfaces risks before they become problems and adversely affect a program. The SEI has developed techniques for surfacing risks by the application of a disciplined and systematic process that encourages program personnel to raise concerns and issues for subsequent analysis.
  • Agile does not have a formal process for identifying risk
  • There is no Risk Register to capture the risks, codify them, assign them ranges or probabilities of occurance
• Risk Analysis - is the conversion of risk data into risk decision‒making information. Analysis provides the basis for the program manager to work on the “right” risks.
  • Agile does not provide a Risk Analysis process
• Risk Planning - turns risk information into decisions and actions (both present and future). Planning involves developing actions to address individual risks, prioritizing risk actions, and creating an integrated risk management plan. The plan for a specific risk could take many forms. For example:
• Mitigate the impact of the risk by developing a contingency plan (along with an identified triggering event) should the risk occur.
• Avoid a risk by changing the product design or the development process.
• Accept the risk and take no further action, thus accepting the consequences if the risk occurs.
• Study the risk further to acquire more information and better determine the characteristics of the risk to enable decision making. 
  • Agile does not provde a process for planning the resuction of risk that is seperate from the development of the software
  • While not a critical issue, it's another example of Agile not actually being risks management, but using the name
• Risk Tracking - consists of monitoring the status of risks and actions taken to ameliorate risks. Appropriate risk metrics are identified and monitored to enable the evaluation of the status of risks themselves and of risk mitigation plans. Tracking serves as the “watch dog” function of management.
  • Risk Trackiing is done in the Risk Register
  • Agile does not provide a Risk Register process
  • One can certainty be built, but it's not a role of Agile software development

• Control – corrects for deviations from planned risk actions. Once risk metrics and triggering events have been chosen, there is nothing unique about risk control. Rather, risk control melds into program management and relies on program management processes to control risk action plans, correct for variations from plans, respond to triggering events, and improve risk management processes.

  • Not clear how Agile provides a control function for managing risk

•  

  Communication & Documentation – Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. Without effective communication, no risk management approach can be viable. While communication facilitates interaction among the elements of the model, there are higher level communications to consider as well. To be analyzed and managed correctly, risks must be communicated to and between the appropriate organizational levels and entities. This includes levels within the development project and organization, within the customer organization, and most especially, across that threshold between the developer, the customer, and, where different, the user. Because communication is pervasive, our approach is to address it as integral to every risk management activity and not as something performed outside of, and as a supplement to, other activities.
  • Communication is independent of any process or framework, so Agile can likley do this as well

With these processes, the management of Risk proceeds as described below

So Now To The Point - Finally

The conjecture that Agile is Risk Management needs to be assessed. Where in the Agile software development process can we find the Risk Management activities described above? Good question. Here's one suggestion:

• Sprint Durations - providing tangible evidence of progress to plan is good project management. Measuring this progress is critical to managing risk. If the plan calls for a specified progress and that progress is not made, then there  is risk to the planned schedule and as a result a risk to the planned cost. But Sprint Durations are not a risk management process, hey are a development process outcome used to TRACK the planned risk reduction
• Retrospectives - at the end of the release, assessment of performance is always a good idea. But that information then needs to be applied to the Risk Handing processes through some process
• Backlog Grooming - this has nothing to do with statistical or probabilistic risk management
• Promoting Transparency - this is always good.
• Frequent Deliveries - the period between deliveries must answer the question how long are we willing to wait before we find out we're late? Agile FORCES this period to be short.

This is the core contribution to managing in the presence of uncertainty. Forced delivery of assessable outcomes on defined boundaries. This provides the necessary feedback to assess progress top plan. This sampling rate should be at a frequency sufficient to take corrective action when the project is in fact late. This is called the Nyquist Sampling Rate and the Nyquist-Shannon theorem from information theory, which says (essentially) what sample rate is sufficient to permits a discrete sequence of samples (the Sprints) to capture all the information from a continuous-time signal of finite bandwidth.= (the underlying project activities).

This answers the question - how long are you willing to wait before you find out you're late? The answer in agile is at the end of every Feature inside the Sprint. In our more traditional world, it's every month with the Integrated Program Performance Report. Agile Forces this to be every week or so.

‡ Epistemic uncertainty, also known as systematic uncertainty, which is due to things we could in principle know but don't in practice. This may be because we have not measured a quantity sufficiently accurately, or because our model neglects certain effects, or because particular data are deliberately hidden. Epistemic uncertainties can be modeled with Probability Distributions. For example, there is a Probability that the Always On function for the Database Farm will fail to switch to the shadows system when called upon to do so. The risk that results from Epistemic uncertainty can be handled with specific activities paid for by the project - testing, redundancies, prototyping. Agile provide a means of handling Epistemic uncertainties and the resulting risk. Build incremental outcomes, test them to confirm they're what the customer wants. Agile contributes this information to the Identify, Analyze, and Plan phases of Risk Management.

† Aleatory uncertainty, also known as statistical uncertainty, which is representative of unknowns that differ each time we run the same experiment. For example, the duration to produce a piece of software cannot be determined in definitive value. There is always some variability in the duration. Aleatory uncertainties and the resulting risk can only be handled with Margin. Cost, Schedule, and Technical margin. Agile as no means of discussing the needed margin, since it's business rhythm is time boxed on fixed intervals - no margin is available.

 

Related articles

Why Guessing is not Estimating and Estimating is not Guessing

Architecture -Center ERP Systems in the Manufacturing Domain

IT Risk Management