Agility and Discipline Made Easy: Practices from OpenUP and RUP

Identifying and addressing top risks in each iteration increases predictability and lowers overall cost.

Problem

A risk is a variable with an unknown or uncertain value that could endanger or jeopardize a project's success.^[3] The key idea in risk management is not to wait passively until a risk materializes and becomes a problem or kills the project, but rather to seek out and deal with risks.

^[3] 3. See Concept: Risk in the Rational Unified Process product.

Ignoring or procrastinating in this area may lead you to invest in the wrong technologies, a bad design, and/or a set of requirements that may not meet stakeholder needs. Unaddressed risks may mean that you run your project with staff that do not have the skills required to do the job, or that you build an application different from the one that stakeholders expect. This is bad software economics. Failure to address risk early in the project means spending more on rework down the road, as many risks become major issues.

Background

I grew up in a very small town, and once a year a fair came to town for the weekend. My favorite game had a bunch of green frogs that kept popping up, the object of which was to knock down the frogs with the hammer provided as rapidly as possible. Managing risk effectively is very much like that game. New risks always keep popping up. As a team, you need to drive them down as fast as you can, focusing on the major risks first.

Just as those green frogs kept coming, you will never be finished dealing with risk. Because risks are volatile, you need to monitor and reassess your situation constantly. Are there any new risks that you need to address? Which risks are more serious than others? Just as you get more points for knocking down some frogs than others, in real life some risks are more serious than others. We want to rig the game of software development to enable us to knock down the biggest frogs early, so that we maximize our points even if we run out of time.

Many risks become a problem due to lack of communication: people do not speak up or, worse, remain silent because they fear retaliation or being ignored by managers or peers. I remember my first major iterative development project. We were building a huge scheduling system that controlled broadcasting distributed across a series of satellites. Our project was divided into two subprojects; mine was responsible for building a system that scheduled all the broadcasting, while the other was building a real-time system for feeding the scheduling information from our system to a series of satellites. The problem was that a Sunday football broadcast, for example, might require last-minute changes to the schedule if the game was running late. We had to decide whether to do late changes in the upstream scheduling system and have the information transferred to the downstream real-time system through a very fast interface, or provide the functionality for making scheduling changes directly in the real-time system. Unfortunately, we didn't resolve these issues until late in the project, because even though several of us were aware of the risk early on, we never escalated the risk to ensure that it received the right level of attention. Once we eventually decided how to proceed, we had to rework parts of the architecture, which took us several months.

Some risks, such as staff turnover and schedule slip, are a reality in most projects and should be taken into account in advance, for example by putting in buffers in the schedule. Other issues are outside the control of the project. If you have no way of influencing something or its consequences, it is not a risk, but rather a constraint that you have to live with.

Now that we have discussed the nature of risks, the need to attack them early on, and the importance of continuously reassessing what risks you are facing, let's look at some concrete guidelines for managing risk.

Applying the Practice

Managing risk requires a multifaceted approach involving the entire team.

• Identify the risks you are facing.

• Document serious risks.

• Openly discuss them inside and outside your team.

• Develop plans for how to address the most serious risks, that is, those that are deemed the most harmful to the project.

• Focus your extended team on addressing risks.

Let's explore each of these activities and discuss some of the benefits of effective risk management.

Identify Risks

At the beginning of each iteration, all team members should jointly consider what risks they are facing and make a list of top risks (or revise an existing list). But how do you find risks? It is good to look for risks by type. You may, for example, look for risks related to resources, business, technical issues, and scheduling. You can then walk through a standard set of risks that often occur in each of these categories.

Finding risks should be everybody's responsibility, and each team member should make contributions to the risk list to ensure that all serious risks have been found. It is, however, important to involve people with the right experience from the domain where the risk originates. Otherwise, you will have problems both finding and addressing the risk. Following is a partial list of risks found in RUP.

Document Serious Risks

Risks can be documented in many ways: on whiteboards, on a Wiki,^[4] in a spreadsheet, or in a risk management tool. For each risk specify:

^[4] 4. A Wiki is a Web site that can be edited by the viewers through their Web browser; see www.wiki.org.

• A name or label for the risk.

• A brief description of the risk.

• The impact of the risk, that is how seriously its occurrence will affect your project outcome.

• The probability of the risk occurring.

• The magnitude of the risk, that is, its impact times probability. This field is typically used to sort the risk list, ensuring that risks of the greatest magnitude are addressed first.

• The owner of the risk, that is, the person responsible for ensuring that the risk is mitigated (mitigating a risk is typically a team effort, but somebody needs to manage that effort).

• The management strategy or plan for addressing the risk. This could include steps to mitigate, avoid, or transfer the risk. We will discuss those three risk strategies more below.

Based on your needs, you may choose a subset of the above attributes, or a number of additional attributes, such as whether it is a technical, nontechnical, architecturally significant, or legal risk.

You should prioritize the risk list according to magnitude and then determine what you need to do to address, typically, the top three to five risks. Table 2.1 provides an example of how to compile a risk list. As you prioritize the list based on magnitude, it is important to understand that your end goal is to identify which risks the team needs to focus on first. Resist the urge to argue about whether the probability is 65 percent or 70 percent, or whether the impact should be a 2 or a 3. Just choose a value that is in the right ballpark (for most projects, this is not a very exact science); if the risk is among the top 15, assess whether you consider it prioritized appropriately, and if not, adjust the probability and/or impact to make sure that your top 5 or 10 risks represent the ones you should focus on.

Table 2.1 shows suggested column headings, but you can use whichever headings are useful for your project, or add more columns as appropriate. Additional columns that could be useful include risk category and status. It is generally worth starting with less information to minimize overhead, and adding more as necessary. Later in this practice we'll add a management plan for each of these risks.

Openly Discuss Risks

Addressing risks should be a priority for everyone throughout the project, but for that to happen, everyone first needs to be aware of the risks to be faced. Many project managers avoid exposing the extended project team to the risk list or are in denial about the existence of the risk. They are afraid that revealing it will look bad to stakeholders and team members and will indicate that they are managing the project poorly. And unfortunately, many company executives do more readily criticize than praise project managers who are open about risks.

This is where the XP value "courage" becomes crucial.^[5] It should be each team member's responsibility to be both brave enough to speak up and responsible enough not to criticize others who do so, even though the risk may point to a flaw in their area of responsibility. To be successful with iterative development (or any project), you need to foster a culture in which you can openly discuss risks and how to address them. Every project faces risks, and living in denial by avoiding the topic of risk makes your project more likely to fail.

^[5] See Beck 2004.

An example of a very effective mechanism for increasing risk visibility to ensure that risks are properly discussed is to put up a huge sign in a common place such as the lunchroom or team room, a so-called information radiator,^[6] listing the top ten risks on the project and who is responsible for addressing each one. As a result, everybody knows what risks the project is facing and feels encouraged to discuss the best way to deal with them.

^[6] 6. See Cockburn 2002.

Develop a Plan for Addressing the Most Serious Risks

Typically, risks need to be addressed from multiple perspectivesfor example, business perspectives such as scope, funding, and resources as well as technical perspectives such as requirements, design, and testing. For each of these perspectives, start with a coarse solution and successively refine it to diminish the risk. Table 2.2 shows examples of actions in the risk management plan that you can take to deal with the risks identified in Table 2.1.

(Adapted from Kroll 2003.)

As with all software development activities, it is important to focus more on execution than planning. Plan enough about how to address the most serious risks so that you can effectively mitigate the top risks. If you are able to focus on only three to five risks at a time, there is no point in doing detailed planning of the top 15 risks.

Focus the Extended Team on Risk Management

Now that you are aware of the risks you face and have a plan for addressing each risk, how can you focus your extended team, including project sponsors and external experts, on using this information to bring about changes in behavior? Here are some considerations:

• Always keep in mind what Tom Gilb^[7] said: "If you don't actively attack the risks, they will actively attack you."

  ^[7] 7. Gilb 1988.

• As you plan an iteration, look at what you would "normally" do for the iteration at hand and then slightly modify the plan to make sure that you deal with your risks. Schedule activities that will mitigate risk. This provides the right focus on risk mitigation, as well as allowing you to understand how much time is spent on it.

• In your daily status meetings (scrums) or weekly staff meetings, use the risk list to help determine what actions to take and what code to develop and test next. Because the risk list represents issues that may make or break the project, it deserves a lot of attention in your staff meetings. Make sure to include updates on key risks as you report risk status.

• Make sure that each team member has access to a current version of the risk list. As necessary, use large, visible charts to ensure that all team members are aware of and react to the most serious risks. Involve extended team members who may be able to help the team mitigate risksbusiness sponsors, higher-level management, external experts, and members from other teams you are collaborating with, such as development teams for systems that you are integrating with.

One thing to keep in mind is that the risk list continually changes. Attacking risk is a constant battle; in each iteration you will be able to reduce or remove some risks, as others grow and new ones appear.

Make Your Ability to Manage Risk a Key Differentiator

One of the key points DeMarco (2003) makes is that if you can effectively manage and mitigate risk, you can take on higher-risk projects, that is, you can assume the risk of being more innovative, leverage newer technologies, undertake more complex projects, take on more challenging business environments, and so on. Effective risk management thus not only allows you to execute your projects more effectively but also enables you to go down roads that others are unable or unwilling to take.

Other Methods

Waterfall processes differ from iterative processes in that they defer integration and testing activities to the latter half of the project, which results in fewer risks being identified early on, as well as making it more difficult for the team to verify that an identified risk has been sufficiently addressed.

All agile and iterative processes focus on the need to manage risk, but with some variations. As an example, in Planning Extreme Programming Kent Beck and Martin Fowler find that "Programmers want to do high-risk stories first, and customers want to tackle high-value stories first. . . . It is the programmers' task to make the risk visible, not to make the decision." XP provides limited guidance on the topic of managing risk, but several practices are designed to drive down risk:

• Make risks widely visible to the team, for example by dedicating whiteboard space for a risk list.

• Use short one- to two-week iterations with continuous integration and testing to provide quick feedback loops.

• Make customers a part of the project team to ensure that both business and technical people evolve and validate the application together.

One difference between the Unified Process and XP is that the Unified Process lifecycle puts greater emphasis on prioritization based on risk, especially technical risk, whereas XP emphasizes less early investment in mitigating technical risk in favor of customer prioritization of what problems to address. Each of the four phases in the Unified ProcessInception, Elaboration, Construction, and Transitioncarries a distinct focus on mitigating a different type of risk. For example, risks associated with understanding the overall project scope, business case, and gaining stakeholder buy-in are the primary focus of the Inception phase.

Scrum does not emphasize risk management as a discipline; it does, however, place a strong emphasis on removing impediments through the daily scrum meetings, at which each team member identifies issues standing in the way of progress on the project. It is the scrum master's job to eliminate these issues rapidly. Scrum also emphasizes mitigation of the specific risk of churn within an iteration by strongly discouraging new change requests to be addressed within an iteration. Instead, change requests are considered for implementation in the next or other future iteration.

Levels of Adoption

This practice can be adopted at different levels:

• Basic. Work on risky areas earlier rather than later. Don't ignore risks as they show up. Determine which risks to focus on in each iteration.

  Prioritizing your work according to risk makes it easier to have shorter iterations by providing a structure for dividing your work into smaller chunks that can fit within an iteration. As an example, identify the minimum steps you need to take to address your top three risks, and use that as a starting point for what to do within the next iteration.

• Intermediate. Update the risk list for every iteration, and make sure that you list at least a handful of risks. Make the risk list clearly visible to all team members. Walk through and update the list in team meetings, and make it a primary tool for discussing status and what actions to take.

  At this level, start to introduce more formality or discipline. The emphasis on risks enables you to determine effectively just what you need to focus on in the next iteration, and thus also what you do not need to focus on. This emphasis typically leads to the ability to have shorter iterations.

• Advanced. Use a risk management tool and a risk management plan to allow a more comprehensive and consistent treatment of risk within your organization. Maintain traceability links between risks and related artifacts and activities that will either help mitigate the risk or are affected by it. As an example of traceability, if you have scheduled five different tasks all related to mitigating a risk, you should be able to find those tasks and their status by calling up the risk on the risk management tool.

  As you introduce yet more formality and tooling, you will increase the learning curve for new team members, hence moving you to the right on the process map. The overhead with the practice is limited, however, and does not significantly affect the length of iterations. This level is appropriate for larger projects and projects that need more ceremony.

Related Practices

• Practice 2: Execute Your Project in Iterations describes how to plan iterative development and divide a project into a series of iterations. Risk drives the actions taken in each iteration.

• Practice 3: Embrace and Manage Change describes what changes to encourage and discourage at what time within a project. Discouraging certain types of changes late in the project is essential to manage risk effectively.

• Practice 10: Prioritize Requirements for Implementation shows how to determine which requirements to address in early iterations to drive the architecture and to mitigate key risks.

Additional Information

Information in the Unified Process

The project management discipline in OpenUP/Basic describes how to identify and manage risks and how to use risk to drive iteration planning. It also provides basic templates for risk management. The project management discipline in RUP expands on this content by adding more elaborate templates and guidelines, as well as examples of risk lists. Formal projects may also leverage the risk management plan in RUP to ensure that risk is properly identified, analyzed, documented, mitigated, monitored, and controlled.

Additional Reading

The following book provides a good understanding of how risk can be used as a competitive differentiator:

Tom DeMarco and Timothy Lister. Waltzing with Bears: Managing Risk on Software Projects. Dorset House, 2003.

The following books provide a good overview of the discipline of risk management:

Barry W. Boehm. "Software Risk Management: Principles and Practices." IEEE Software, January 1991, pp. 3241.

Marvin Carr et al. Taxonomy Based Risk Identification. Software Engineering Institute, 1993.

Robert Charette. Software Engineering Risk Analysis and Management. McGraw-Hill, 1989.

Capers Jones. Assessment and Control of Software Risks. Yourdon Press, 1994.

Dale Karolak. Software Engineering Risk Management. IEEE Computer Society Press, 1996.