User:Mtoddne/sandbox

The dual goals of risk management are: to maximize the positive impacts that increase the value that a project delivers, and to reduce the negative impacts that can decrease the value delivered; up to and including project failure. Effectively and efficiently satisfying these goals requires the appropriate skill, knowledge, tools and techniques. Risk management on projects provides many benefits, including: an increased ability to anticipate and avoid problems and surprises, an improved ability to negotiate desired outcomes, increased customer satisfaction, and improved on time and on budget project delivery. Despite the benefits, risk management is frequently overlooked on projects, and often goes unnoticed on projects when it is applied successfully. The application, or lack of application, of risk management many times is recognized only when a major impact is realized.

Risk management is an explicit function in traditional project management as defined by the Project Management Institute (PMI) in “A Guide to the Project Management Body of Knowledge (PMBOK)”. It is comprised of six processes: risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and the on-going monitoring and controlling of risks. Traditional risk management involves the development and maintenance of a series of risk related deliverables, including: a risk management plan, contingency and fallback plans, a risk breakdown structure, a risk register, and a top ten risk list for tracking risks. And it encompasses the use of various qualitative and quantitative risk analysis techniques: probability/ impact matrix, expected monetary value, Monte Carlo analysis, and sensitivity analysis.

With the growing use of Agile development approaches to design and build software products, it is important to understand how risk management is impacted by Agile. This article describes:
 * How Agile approaches inherently manage the risks associated with software development projects.
 * How to manage the risks that are more prevalent on Agile projects than on projects that follow traditional process driven development methodologies.

Introduction
Agile software development is rapidly becoming the software application approach of choice for many organizations. In a 2010 Forrester Research survey, 38.6% of respondents identified Agile as the approach that most closely reflects their current development methodology; only 9.4% of the respondents identified Waterfall as their methodology preference. A key reason why organizations choose to use Agile approaches to develop software is because Agile inherently addresses the basic problem of software development: risk. This includes the risks associated with delivery timeframes, the overall quality of delivered solutions, understanding true business needs, delivering features that don’t add value to the business, overall project success, and staff turnover. Agile approaches, however, introduce new risks associated with heightened skill requirements, people challenges, and team based decision making. It is important that organizations, that choose to use Agile, develop the appropriate strategies to mitigate these risks just as they develop strategies to mitigate the risks associated with traditional application development.

Project success criteria
User involvement, adequate project planning, requirements that are clearly understood, realistic expectations, and small project milestones, were identified by the Standish Group as five of the most important criteria leading to the overall success of software development projects. If these project success criteria aren’t adequately satisfied the risks of cost overruns, time overruns, and product content deficiencies, will likely increase. A significant element of success is iterative and incremental delivery of software; “growing” software through small, short timeframe development phases, which enables incremental learning and understanding of the true user requirements. There are many variations of Agile development approaches. A good Agile approach, however, should inherently address the aforementioned information technology success criteria.

Extreme Programming
One Agile development approach is Extreme Programming (XP). XP is defined by Kent Beck as “a light-weight methodology for small-to-medium sized teams developing software in the face of vague or rapidly changing requirements.” The ideal XP project life-cycle consists of a series of exploration, planning, iterations toward release, and productizing phases; where the natural state of XP is evolutionary growth. The cycle continues until the death of the system; that is when the customer can’t think of any more enhancement that are needed to the system, or the system is no longer needed. The following table identifies how a XP development approach inherently mitigates specific software development risks.

Agile project management
Risk management is an inherent component of an Agile project management approach. Risk identification, risk analysis, and risk response planning are integral elements of iteration planning meetings, project retrospectives, and daily team stand-up meetings. On Agile projects the entire team works in a cooperative and collaborative manner to manage risk on a daily basis. Each team member is asked daily to identify any issues or potential issues (risks) that are hindering their progress. Risk monitoring occurs through the use of project burn down charts, task boards, and the daily stand-up meetings. And risk assessments are done at the conclusion of each iteration, through retrospective meetings.

According to Smith and Pichler an Agile risk management best practice is to integrate risk management tasks into iteration planning meetings to ensure potential risks are identified and planned for early on in an iteration. Their proposed process which integrates risk management with iteration planning involves: reviewing backlog items for potential risks, performing analysis and prioritization of the risks, developing and mapping response plans to the backlog items, selecting the backlog items to be included in the iteration taking into account risk, and then setting the objectives for the iteration.

Continuous Integration, Testing, and Delivery
Three best practice aspects of Agile development that facilitate the inherent management of risk are: continuous integration, continuous testing, and continuous delivery. Continuous integration is required to support continuous testing and delivery. Supporting the Agile goal of “...a workable and deployable...” code base requires the continuous integration of software modules. Continuous testing, supported by automated tests, provides more frequent feedback to development teams on the quality of their work. In addition, early and continuous testing ensures that architectural risks are identified and resolved early in the project life-cycle. Continuous delivery provides working software early and often. The experience gained in the production use of this software provides early and frequent feedback on possible improvements that can be made in future iterations. This helps to ensure the continuous advancement of the system.

Design Thinking
The product design consulting company IDEO, and its predecessors, have successfully used Design Thinking to facilitate the development of many innovative products, including: the first laptop computer, Apple’s original mouse, the Oral-B toothbrush, and the Palm personal digital assistant. This approach inherently manages risk, while delivering innovative solutions, through an iterative and incremental design and delivery methodology.

Each Design Thinking project is comprised of a multi-disciplinary team including experienced product designers. The project team works collaboratively throughout the life of a project. A project begins with an inspiration phase, where group observation of a problem or opportunity is used to frame the project vision. Next the project seamlessly transitions into ideation, where the team uses what they’ve observed as input to brainstorming sessions that are used to generate solution ideas. Then selected ideas are vetted through product prototyping. A project then iterates through inspiration and ideation, as many times as necessary, until an acceptable solution, which satisfies the vision, is reached. This leads to the implementation phase, where the ideal solution is transformed into a finished product.

Product prototyping is a key aspect of the Design Thinking approach. Prototyping helps in the inherent management of risk by recognizing the practical reality of innovative product development: people don’t always know what the right solution is until they experience it. Prototyping facilitates the customer gaining a concrete understanding of a solution’s potential, and minimizes the communications issues that can occur with traditional, non-customer-experienced based, requirements gathering methodologies.

Explicit risk management
Although following an Agile approach can facilitate the inherent management of many risks that befall information technology projects, there are some risks that may be more prevalent on Agile projects. These risks pertain to the “people over process”, collaborative decision making, and “just barely good enough” approaches that are foundational to Agile development. This section identifies the key risks associated with these elements, and provides recommendations for mitigating the risks.

People over process
A central aspect of Agile development is a focus on individuals and their interactions with one another over development process. The success of Agile depends on the motivation, knowledge, and abilities of each individual on a team. This includes the ability to work in a collaborative fashion with other individuals, including the daily interaction with business subject matter experts. This dependency on individuals creates a number of somewhat unique challenges, or risks that must be properly mitigated. The following table highlights these challenges/ risks and identifies response plans that can be employed to mitigate each challenge/ risk.

Collaborative decision making
With traditional project management approaches, many of the day to day decisions are made by the project manager. One of the key aspects of Agile development approaches, on the other hand, is team empowerment, which implies team based decision making. This is “rooted” in the Agile manifesto proclamation that “individuals are more important than processes and tools”. Team empowerment and decision making does however introduce the risk that decisions may be influenced by two common group decision making problems : Groupthink, which is “a deterioration of mental efficiency, reality testing, and moral judgment that results from in-group pressures”, and the Abilene Paradox, which describes a group decision making situation where the group decides to take a course of action that none of the group members would take individually

According to McAvoy and Butler, there are several steps that a project team can take to mitigate the risks associated with group empowerment and decision making. First, when considering alternate plans or options to solve a problem, the team should be separated into two or more sub-groups who will work independently to define alternatives for solving the problem. Second, a devil’s advocate should be assigned. This person is responsible for challenging decisions made by the team; getting the team to consider alternate solutions to a problem. Three other recommendations that can be employed to mitigate the risks associated with group empowerment and decision making are: establish an environment where group decision making techniques can be learned and practiced, use a democratic system which encourages individual participation in group decisions, assign a trained and experienced person to the role of group facilitator.

Just barely good enough
One of the tenants of Agile development is “Just Barely Good Enough” design. Design decisions are based on what is known and needed for the current iteration. The goal is to do just enough design, but not too much. The risk with this approach is that later iterations may uncover design flaws introduced through the development completed in earlier iterations. This can lead to rework and complexity that is introduced through multiple iterations of rework.

Mitigating the risks associated with “Just Barely Good Enough” design requires an understanding of which aspects of an application contain the highest risk. Iterations should be organized to reduce risk, with the highest risk areas being addressed in earlier iterations of a project. Risks that fall into the high risk category include: risks associated with the use of new techniques and technologies, risks related to the underlying application, platform, and database architectures, performance and reliability risks, and risks associated with building a system that may not solve the real business problem.