Agile Risk Management: Recognizing Risks

You can’t capture risk with your camera. You need to have a conversation with a diverse group of stakeholders.

At a recent Q&A session I was asked: Where could a person get their project risks? I stifled a smart-alecky answer that would have included driving to the grocery store, and decided that the question that was being asked was really: How do I go about recognizing and capturing risks? Perhaps a more boring question, but far more important. If I answered the first question the answer would have been that risks are generated by the interaction of the project with other projects, applications, the business, technology and world (risk categories) – pretty much the existence of a project could be considered a risk magnet. The answer to the second question is that once you have a risk magnet (a project) you will need to ask as many different people as is feasible to recognize the possible risks. The discussion of risk is always appropriate; however, the typical meeting/events and the types of people to consider in the conversation needs to be planned. The discovery process typically follows the requirements/user story discovery process outlined below.

 

Risk Tolerance

This is a risk I’m willing to take.

A risk is the potential or exposure to danger, harm or loss. The concept of risk is understandable to everyone involved in delivering work, at least at a basic level. We understand that “stuff” can happen when we least expect it to happen, in a project or in our individual lives.  The question is whether any specific risk or the accumulation of risks is worth taking action to avoid.  Which risks are perceived to be so daunting that they need to be actively avoided is based on personal and organizational perspectives and biases.  The technical term for this behavior is risk tolerance.  In response to Internal and External Risk, Matt Williams commented:

“An important step that I think often gets overlooked is the act of defining a risk tolerance.While many teams (or organizations) may have an intuitive sense of their risk tolerance, I think it’s helpful to have an explicit, conscious discussion about risk tolerance.”

We can define risk tolerance in simple terms as how much value are we willing to lose if a risk materializes.  The impact of a risk materializing and becoming an issue can range from rework, a reduction in returns, shifting positive perceptions or a compliance failure. A reflection of risk tolerance, in the financial markets, is the difference between the rates of return for a financial instrument (e.g. stocks, bonds, and others) and another financial instrument (such as a treasury bond). In finance the higher the risk the higher the return is required to balance.

If risk tolerance is important for the governance of software development and maintenance projects, we need a mechanism to define tolerable and intolerable risks before we decide how to ROAM risks.  Assessing risk tolerance is an evaluation of the willingness to take on risks and how much “exposure” from threats from outside the company are acceptable.

In a further comment Mr. Williams went on:

“I think risk tolerance is very context-specific. It depends in part on the organization – its size, culture, mission, etc. – in part on the project and its specific nature, and in part on the nature of the risk itself.”

Every person and organization has a different level of risk tolerance.  We can visualize risk tolerance in a chart as a curve. Risk tolerance is a balance between probability the probability a risk occurs and the impact that will be realized if it does occur.  In most software development and maintenance efforts defining the risk/tolerance curve is an implicit rather than explicit act.  The issue is that a team’s or organization’s level of  risk tolerance will cause different behaviors.  Risk avoiders, teams or organizations that fear the impact of risks, will tend to do more research or analysis before committing to a direction.  Risk takers tend to try approaches and then pivot if needed.

Risk tolerance affects how everyone in an organization behaves.  Rarely, however, does everyone in an organization have the same tolerance towards risk.  Defining or at least developing an understanding of a team’s risk tolerance isn’t merely an academic discussion.  Differences in risk tolerance can generate tensions and risks of its own, therefore at the very least teams need in the words of Mr. Williams, “have an explicit, conscious discussion.”

Current Risk Arc:

Internal and External Risks

Incorporating the Idea of External Risk into Agile Efforts

Risk Tolerance (Current) 

******

 

 

Incorporating the Idea of External Risk into Agile Efforts

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.  

 

Agile Risk Management: The Need Still Exists

 

Hand Drawn Chart Saturday

I once asked the question, “Has the adoption of Agile techniques magically erased risk from software projects?” The obvious answer is no, however Agile has provided a framework and tools to reduce the overall level of performance variance. Even if we can reduce risk by damping the variance driven by complexity, the size of the work, process discipline and people, we still need to “ROAM” the remaining risks. ROAM is a model that helps teams identify risks. Applying the model, a team would review each risk and classify then as:

• Resolved, the risk has been answered and avoided or eliminated.
• Owned, someone has accepted the responsibility for doing something about the risk.
• Accepted, the risk has been understood and the team has agreed that nothing will be done about it.
• Mitigated, something has been done so that the probability or potential impact is reduced.

When we consider any risk we need to recognize the two attributes: impact and probability.  Impact is what will happen if the risk becomes something tangible. Impacts are typically monetized or stated as the amount of effort needed to correct the problem if it occurs. The size of the impact can vary depending on when the risk occurs. For example, if we suddenly decide that the system architecture will not scale to the level required during sprint 19, the cost in rework would be higher than if that fact were discovered in sprint 2. Probability is the likelihood a risk will become an issue. In a similar manner to impact, probability varies over time.

We defined risk as “any uncertain event that can have an impact on the success of a project.” Does using Agile change our need to recognize and mitigate risk?  No, but instead of a classic risk management plan and a risk log, a more Agile approach to risk management might be generating additional user stories. While Agile techniques reduce some forms of risk we still need to be vigilant. Adding risks to the project or program backlog will help ensure there is less chance of variability and surprises.

 

Agile Risk Management: People

People are chaotic.

Have ever heard the saying, “software development would be easy if it weren’t for the people”? People are one of the factors that cause variability in the performance of projects and releases (other factors also include complexity, the size of the work, and process discipline.) There are three mechanisms built into most Agile frameworks to address an acceptance of the idea that people can be chaotic by nature and therefore dampen variability.

1. Team size, constitution and consistency are attributes that most Agile frameworks have used to enhance productivity and effectiveness that also reduce the natural variability generated when people work together.
   1. The common Agile team size of 7 ± 2 is small enough that team members can establish and nurture personal relationships to ensure effective communication.
   2. Agile teams are typically cross-functional and include a Scrum master/coach and the product owner. The composition of the team fosters self-reliance and the ability to self-organize, again reducing variability.
   3. Long lived teams tend to establish strong bonds that foster good communication and behaviors such as swarming. Swarming is a behavior in which team members rally to a task that is in trouble so that team as a whole can meet its goal, which reduces overall variability in performance.
2. Peer reviews of all types have been a standard tool to improve quality and consistency of work products for decades. Peer reviews are a mechanism to remove defects from code or other work product before they are integrated into larger work products. The problem is that having someone else look at something you created and criticize it is grating. Extreme programing took classic peer reviews a step further and put two people together at one keyboard, one typing and the other providing running commentary (a colloquial description of pair programing). Demonstrations are a variant of peer reviews. Removing defects earlier in the development process through observation and discussion reduces variability and therefore the risk of not delivering value.
3. Daily stand ups and other rituals are the outward markers of Agile techniques. Iteration/sprint planning keeps teams focused on what they need to do in the short-term future and then re-plans when that time frame is over. Daily stand-ups provide a platform for the team to sync up on a daily basis to reduce the variance that can creep in when plans diverge. Demonstrations show project stakeholders how the team is solving their business problems and solicit feedback to keep the team on track. All of these rituals reduce potential variability that can be introduced by people acting alone rather than as a team with a common goal.

In information technology projects of all types, people transform ideas and concepts into business value. In software development and maintenance, the tools and techniques might vary but, at its core, software-centric projects are social enterprises. Get any group of people together to achieve a goal is a somewhat chaotic process. Agile techniques and frameworks have been structured to help individuals to increase alignment and to act together as a team to deliver business value.

 

Agile Risk Management: Ad-hoc Processes

The CFO here wants to move away from vague generic invoices because he feels (rightly so) that the agency interprets the relationship as having carte blanche…

There are many factors that cause variability in the performance of projects and releases, including complexity, the size of the work, people and process discipline. Consistency and predictability are difficult when the process is being made up on the spot. Agile has come to reflect (at least in practice) a wide range of values ranging from faster delivery to more structured frameworks such as Scrum, Extreme Programing and Scale Agile Framework Enterprise. Lack of at least some structure nearly always increases the variability in delivery and therefore the risk to the organization.

I recently received the following note from a reader (and listener to the podcast) who will remain nameless (all names redacted at the request of the reader).

“All of the development is outsourced to a company with many off-shore and a few on-site resources.

The development agency has, somehow, sold the business on the idea that because they are “Agile”, their ability to dynamically/quickly react and implement requires a lack of formal “accounting.”  The CFO here wants to move away from vague generic invoices because he feels (rightly so) that the agency interprets the relationship as having carte blanche to work on anything and everything ever scratched out on a cocktail napkin without proper project charters, buy-in, and SOW.”

This observation reflects a risk to the organization of an ill-defined process in terms the value that get delivered to the business, financial risk and from the risk to customer satisfaction. Repeatability and consistency of process are not a dirty words.

Scrum and other Agile frameworks are light-weight empirical models. At their most basic levels they summarized as:

1. Agree upon what your are going to do (build a backlog),
2. Plan work directly ahead (sprint/iteration planning),
3. Build a little bit while interacting with the customer (short time box development),
4. Review what has been done with the stakeholders (demonstration),
5. Make corrections to the process (retrospective),
6. Repeat as needed until the goals of the work are met.

Deming would have recognized the embedded plan-do-check-act cycle. There is nothing ad-hoc about the frame even though it is not overly prescriptive.

I recently toured a research facility for a major snack manufacturer. The people in the labs were busy dreaming up the next big snack food. Personnel were involved in both “pure” and applied research, both highly creative endeavors. When I asked about the process they were using what was described was something similar to Scrum. Creatively being pursued within a framework to reduce risk.

Ad-hoc software development and maintenance was never in style. In today’s business environment where software in an integral the delivery of value, just winging the process of development increases risk of an already somewhat risky proposition.

 

Agile Risk Management: Dealing With Size

Overall project size influences variability.

Risk is reflection of possibilities, stuff that could happen if the stars align. Therefore projects are highly influenced by variability. There are many factors that influence variability including complexity, process discipline, people and the size of the work. The impact of the size can be felt in two separate but equally important manners. The first is the size of the overall project and second is the size any particular unit of work.

Overall project size influences variability by increasing the sheer number of moving parts that have to relate to each other. As an example, the assembly of an automobile is a large endeavor and is the culmination of a number of relatively large subprojects. Any significant variance in how the subprojects are assembled along the path of building the automobile will cause problems in the final deliverable. Large software projects require extra coordination, testing, integration to ensure that all of the pieces fit together, deliver the functionality customers and stakeholders expect and act properly. All of these extra steps increase the possibility of variance.

Similarly large pieces of work, user stories in Agile, cause similar problems as noted for large projects, but at the team level. For example, when any piece of work enters a sprint the first step in the process of transforming that story into value is planning. Large pieces of work are more difficult to plan, if for no other reason that they take longer to break down into tasks increasing the likelihood that something will not be considered generating a “gotcha” later in the sprint.

Whether at a project or sprint level, smaller is generally simpler, and simpler generates less variability. There are a number of techniques for managing size.

1. Short, complete sprints or iterations. The impact of time boxing on reducing project size has been discussed and understood in mainstream since the 1990’s (see Hammer and Champy, Reengineering the Corporation). Breaking a project into smaller parts reduces the overhead of coordination and provides faster feedback and more synchronization points, which reduces the variability. Duration of a sprint acts as constraint to the amount of work that can be taken and into a sprint and reasonably be completed.
2. Team sizes of 5 to 9 are large enough to tackle real work while maintaining the stabile team relationships needed to coordinate the development and integration of functionality that can potentially be shipped at the end of each sprint. Team size constrains the amount of work that can enter a sprint and be completed.
3. Splitting user stories is a mechanism to reduce the size of a specific piece of work so that it can be complete faster with fewer potential complications that cause variability. The process of splitting user stories breaks stories down into smaller independent pieces (INVEST) that be developed and tested faster. Smaller stories are less likely to block the entire team if anything goes wrong. This reduces variability and generates feedback more quickly, thereby reducing the potential for large batches of rework if the solution does not meet stakeholder needs. Small stories increases flow through the development processes reducing variability.

I learned many years ago that supersizing fries at the local fast food establishment was a bad idea in that it increased the variability in my caloric intake (and waistline). Similarly, large projects are subject to increased variability. There are just too many moving parts, which leads to variability and risk. Large user stories have exactly the same issues as large project just on a smaller scale. Agile techniques of short sprints and small team size provide constraints so that teams can control the size of work they are considering at any point in time. Teams need to take the additional step of breaking down stories into smaller pieces to continue to minimize the potential impact of variability.

 

Agile Risk Management: Dealing With Complexity

Software development is inherently complex and therefore risky. Historically there have been many techniques leveraged to identify and manage risk. As noted in Agile and Risk Management, much of the risk in projects can be put at the feet of variability. Complexity is one of the factors that drives complexity. Spikes, prioritization and fast feedback are important techniques for recognizing and reducing the impact of complexity.

1. Spikes provide a tool to develop an understanding of an unknown within a time box. Spikes are a simple tool used to answer a question, gather information, perform a specific piece of basic research, address project risks or break a large story down. Spikes generate knowledge, which both reduces the complexity intrinsic in unknowns and provides information that can be used to simplify the problem being studied in the spike.
2. Prioritization is a tool used to order the project or release backlog. Prioritization is also a powerful tool of reducing the impact of variability. It generally easier to adapt to a negative surprise in a project earlier in the lifecycle. Teams can allocate part of their capacity to the most difficult stories early in the project using complexity as a criterion for prioritization.
3. Fast feedback is the single most effective means of reducing complexity (short of avoidance). Core to the DNA of Agile and lean frameworks is the “inspect and adapt” cycle. Deming’s Plan-Do-Check-Act cycle is one representation of “inspect and adapt” as are retrospectives, pair-programming and peer reviews. Short iterative cycles provide a platform to effectively apply the model of “inspect and adapt” to reduce complexity based on feedback. When teams experience complexity they have a wide range of tool to share and seek feedback ranging from daily stand-up meetings to demonstrations and retrospectives.
   Two notes on feedback:
   1. While powerful, feedback only works if it is heard.
   2. The more complex (or important) a piece of work is, the shorter the feedback cycle should be.

Spikes, prioritization and feedback are common Agile and lean techniques. The fact that they are common has led some Agile practitioners to feel that frameworks like Scrum has negated the need to deal specifically with risks at the team level. These are powerful tools for identifying and reducing complexity and the variability complexity generates however they need to be combined with other tools and techniques to manage the risk that is part of all projects and releases.

 

Agile and Risk Management

We brush our teeth to avoid cavities; a process and an outcome.

There is no consensus on how risk is managed in Agile projects or releases or whether there is a need for any special steps. Risk is defined as “any uncertain event that can have an impact on the success of a project.” Risk management, on the other hand, is about predicting the future. Risk management is a reflection of the need manage the flow of work in the face of variability. Variability in software development can be defined as the extent that any outcome differs from expectations. Understanding and exploiting that variability is the essence of risk management. Variability is exacerbated by a number of factors, such as the following.

1. Complexity in any problem is a reflection of the number of parts to the problem, how those parts interact and the level of intellectual difficulty. The more complex a problem, the less likely you will be able to accurately predict the delivery of a solution to the problem. Risk is reduced by relentlessly focusing on good design and simplifying the problem. Reflecting the Agile principle of simplicity, reducing the work to only what is absolutely needed is one mechanism for reducing variability.
2. Size of project or release influences the overall variability by increasing the number of people involved in delivering an outcome and therefore the level of coordination needed. Size is a form of complexity. Size increases the possibility that there will be interactions and dependencies between components of the solution. In a perfect world, the work required to deliver each requirement and system component would be independent of each other, however when this can’t be avoided projects need mechanisms to identify and deal with dependencies. An example of a mechanism to address complexity created by size is the release planning event is SAFe.
3. Ad hoc or uncontrolled processes can’t deliver a consistent output. We adopt processes in order to control the outcome. We brush our teeth to avoid cavities; a process and an outcome. When a process is not under control, the outcome is not predictable. In order for a process to be under control, the process needs to be defined and then performed based on that definition. Processes need to be defined in as simple and lean a manner possible to be predictable.
4. People are chaotic by nature. Any process that includes people will be more variable than the same process without people. Fortunately we have not reached the stage in software development where machines have replaced people (watch any of the Terminator or Matrix movies). The chaotic behavior of teams or teams of teams can be reduced through alignment. Alignment can be achieved at many levels. At release or program level, developing a common goal and understanding of business need helps to develop alignment. At a team level, stable teams helps team members build interpersonal bonds leading to alignment. Training is another tool to develop or enhance alignment.

Software development, whether the output maintenance, enhancements or new functionality a reflection of processes that have a degree of variability. Variability, while generally conceived of as being bad and therefore to be avoided, could be good or bad. Finding a new was to deliver work that increases productivity and quality is good. The goal for any project or release is to reduce the possibility of negative variance and then learning to use what remains to best advantage.

 

Stand-up Meetings: Add-ons

Stay focused!

 

There are very few add-ons that can make a daily stand-up meeting better. In fact most add-ons shift the focus of the meeting and could easily be classified as process problems. However, there are two add-ons that can add value to the stand-up meeting process: trolling for risks and hand-offs.

Trolling for risks. Anyone that has ever felt responsibility for the outcome of a project has had that nagging feeling that something was lurking just over the horizon that could reduce the value you are delivering. Project risks reflect the potential for something to go wrong. No one wants to have a risk that should be seen coming to catch them off guard. Therefore I periodically add a fourth question to the stand-up meeting questions: “Are there any project risks you are more concerned about this sprint than last sprint?” The goal is expose any new risks or any risks that are becoming more risky. At a project level I suggest adding this to the stand-up discussion once per two week sprint and do not let the conversation expand beyond the 15 minute time box. If the project has suddenly become so risky that more time is needed, treat the changed risk status as a blocker and have the scrum master pursue identifying the root cause so that specific action can be taken. Stand-ups for a program (very large project or a related group of projects) may need to monitor risk on a daily basis.

Hand-offs. Project teams are often distributed across continents, which can be used to a team’s advantage so that work begun in one time zone can be handed off and to be continued at the beginning of another team member’s day. This technique is often called “following the sun.” In order for this technique to work, the team members that are involved in the hand-off must understand that the hand-off is occurring, the goal of the shared task and the current status of the work. The daily stand-up meeting plays a critical role in this process. Involved team members can use their update to alert those they are handing work off to about the current status of their shared task or to schedule follow-on discussions if a more in-depth hand-off is needed. One common example of this practice is when developers are in one location and testers in another. The approach is first planned in sprint planning then coordinated during the daily stand-up meeting and other person-to-person interactions. The daily stand-up meeting generally acts as a formal control mechanism while conversation outside the meeting is less formal and more collaborative.

The stand-up meeting serves a very specific set of planning and coordination purposes. Add-ons generally push the daily stand-up meeting away from that purpose therefore become process problems. There are a few add-ons that fit well within the purpose of the meeting and the 15 minute time box. These add-ons focus on planning and coordinating and help the team get their work done rather than reporting on how the work is being done.