## 4.6 Risks Agile Risk Management involves removing obstacles that impede the work progress of the project team members. These obstacles, also known as impediments or roadblocks, are any situation or event that prevent or block the progress of work during an iteration. Removing these obstacles reduces the overall risk of a PM2- Agile Project. It's often mentioned that PM2-Agile projects are less risky by nature. This is true and the reason goes back to the foundations of the Agile Manifesto. PM2 Project Risk Management activities are also used in PM2-Agile and performed throughout every iteration. The following Agile Manifesto principles represent a clear example of how PM2-Agile is less risky by nature. - **Collocated teams** - Bringing the project team and the client together, preferably in the same physical area, leads to better communication and less wasted time. - **Simplicity** - Maximize the amount of work not done: The team should only concentrate on the minimum amount of work that needs to be performed. Wasteful processes should be eliminated and the practice of Gold banned. Removing waste is a risk management practice that forms the foundation of PM2-Agile. - **Regular Reflection** - By continuously improving processes throughout the project, risk is exponentially reduced. Process improvements should be immediately implemented in the following iterations, ensuring that these same risks do not occur again in the project. In PM2-Agile, there are two types of Risk Management approaches that help materializing how Agile is perfectly aligned with the PM2 Risk Management Process. Those are: - **Implicit** - It's what is intrinsic to the Agile process, making risk management coming out "naturally" from the natural iterative planning and review process and activities. - **Explicit** - Refers to implementing risk management strategies in order to identify, assess and mitigate project risk by using specific agile risk management tools and techniques. To give a better idea of the concepts of Implicit and Explicit Risk management in PM2-Agile projects, below there's an explanation of how each of these concepts apply to each of the four steps foreseen in PM2 to manage risk. - **Identify Risks** - In PM2-Agile, the whole team implicitly identifies risks during ceremonies like Iteration Planning, Daily Stand-up, Iteration Retrospective, etc, recording their results in white boards and other tools. If the team is using an explicit strategy, additional topics can be added to a planning meeting agenda to explicitly identify and prioritize risks. The result will influence the work that is being planned for that particular iteration. Additionally, risks can be continuously identified during the Daily stand-up meeting, either as obstacles (implicit strategy) or as risks (explicit strategy). - **Risk Assessment** - Projects using PM2-Agile generally perform only "qualitative analysis" at the expense of “quantitative analysis” as Agile short development cycles and constant reviews make this feasible and effective. Qualitative elements like Risk Likelihood and Risk Impact, based on a relative scale of one to five, make Risk Assessment a team exercise and provide consolidated information to the risk information radiators. - **Develop a Risk Response Strategy** - In PM2-Agile, the entire team is implicitly involved in risk response planning in every project iteration, as they all participate in the planning meetings, daily stand-ups, retrospectives, etc. When an explicit approach is required to manage risks, tools and techniques such as risk-based spikes or risk Boards help to develop immediate risk response and implementation strategies. - **Control Risk Response activities** - Risk response is a continuous and ongoing process described In PM2. Due to its iterative nature, PM2-Agile has these monitoring and controlling processes implicit. Daily stand-up meetings allow risks to be monitored regularly by exposing potential threats and obstacles. - In PM2-Agile, risk reassessment occurs at least by the end of the iteration, during the Iteration retrospective, where previous risks and concerns are revisited to determine changes to be implemented in future iterations.