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 identifying where to best deploy scarce resources for the most significant 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 are the essence of effective risk management. Risk management should occur throughout the program's lifecycle, 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. These estimates are necessary to assess 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 rigorously or validly 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 essential for modeling the future performance of a project's cost, Schedule, and technical outcomes 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 a 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 Events based on uncertainties, where there?is a probability of something happening unfavorably impacting the project?
• Are described by?the 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?comes from the Latin?alea. For example, in a game of chance, stochastic variability's are the natural randomness of the process and is characterized by a probability density function (PDF) for their range and frequency.?Since these variabilities 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, and technical performance.
• We can state the probability range of these variances within the?Probability Distribution Function.

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

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 suggestions that Agile is Risk Management. First, could you look at the risk management processes and what they entail 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 applying 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 occurrence

Risk Analysis?- is the conversion of risk data into risk decision?making information. The 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 measures 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 Risk by changing the product design or the development process.
• Accept the Risk and take no further action, so you can accept the consequences if the Risk happens.
• Study the Risk further to acquire more information and better determine the characteristics of the Risk to enable decision-making.?
• Agile does not provide a process for planning the reduction of Risk that is separate from the development of the software.
• While not a?critical?issue, it's another example of Agile not being risk 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 evaluate the level of risks themselves and risk mitigation plans. Tracking serves as the "watchdog" function of management.

• Risk Tracking is done in the Risk Register
• Agile does not provide a Risk?Register?process
• One can?be?built, but it's different from the 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. Instead, 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 model's center to emphasize its pervasiveness and criticality. Without effective communication, no risk management approach can be viable. While communication facilitates interaction among the model elements, 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 likely do this.

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 specified improvement and that progress is not made, then there?is a risk to the planned Schedule and, as a result, a risk to the planned cost. But Sprint Durations are not a risk management process; they are a development process outcome used to?TRACK?the planned risk reduction.
• Retrospectives - at the end of the release, an assessment of performance is always a good idea. But that information?must 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?of how long we are 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 the progress top plan. This?sampling rate?should be at a sufficient frequency to take corrective action when the project is 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?permit?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, is due to things we could, in principle, know but don't in practice. This may be because we have not accurately measured a quantity, our model neglects specific 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, and prototyping. Agile provides a means of managing Epistemic uncertainties and the resulting Risk. Build incremental outcomes, and test them to confirm they're what the customer wants. Agile contribute this information to the Identify, Analyze, and Plan phases of Risk Management.

??Aleatory uncertainty, also known as?statistical uncertainty, 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 has no means of discussing the needed Margin since its business rhythm is?time-boxed?on fixed intervals - no margin is available.