This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
+12.0 Risk Management and Agile Software Development
The naturally occurring uncertainties (Aleatory) in cost, schedule, and technical performance can be modeled in a Monte Carlo Simulation tool. The Event Based uncertainties (Epistemic) require capture, modeling of their impacts, defining handling strategies, modeling the effectiveness of these handling efforts, and the residual risks, and their impacts of both the original risk and the residual risk on the program.
Risk Management is how Adults Manage Projects– Tim Lister
+ Risk Management is about Making Decisions in Presence of Uncertainty
n All project work is uncertain.
n Agile development can inform Risk Management, but it itself is not Risk Management.
n Rapid feedback, small increments of produced software, close knit teams of developers with customers, all help reduce risk – but risk produced by uncertainty.
n Those risks still have to be managed outside the development processes of Agile, since they impact other aspects of the project beyond the production of software.
1. Hope is not a strategy2. No single point estimate of cost or schedule can be correct3. Cost, Schedule, and Technical Performance are inseparable4. Risk management requires adherence to a well defined
process5. Communication is the Number One success factor
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 identification of where to best deploy scarce resources for the greatest impact on the program’s risk profile.
Management and staff 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 is the essence of effective risk management.
Risk management should occur throughout the lifecycle of the program and strategies should be adjusted as the risk profile changes.
n Risk Statement ‒ A concise description of an individual risk that can be understood and acted upon. Risk statements have the following structure: “Given that [CONDITION], there is a possibility of [DEPARTURE] adversely impacting [ASSET], which can result in [CONSEQUENCE]. †
n The CONDITION is a single phrase that describes the current key fact-based situation or environment that is causing concern, doubt, anxiety, or uneasiness.
n The DEPARTURE describes a possible change from the (agency, program, project, or activity) baseline project plan. It is an undesired event that is made credible or more likely as a result of the CONDITION.
n The ASSET is an element of the organizational unit portfolio (OUP) (analogous to a WBS). It represents the primary resource that is affected by the individual risk.
n The CONSEQUENCE is a single phrase that describes the foreseeable, credible negative impact(s) on the organizational unit’s ability to meet its performance requirements.
+ Some More Words about the Riskthat Results from Uncertaintyn Risk has two dimensions
n The degree of possibility that an event will take place or occur sometime in the future
n The consequences of that event, once it has occurred
n The degree of possibility is qualified as the Probability of Occurrence (event based) or a Probability Distribution Function (a distribution of variability's of a random number)
n The consequences are usually taken to be undesirable and qualified as the magnitude of harm and the remaining probability of a recurrence of the same risk.
n The product vision statement helps unify the project team's definition of product goals, mitigating the risk of misunderstandings about what the product needs to accomplish.
n While creating the product vision, the project team may consider risk on a very high level, in conjunction with the marketplace, customers, and organizational strategy.
n At the Product Vision level, identify risks that will unfavorably impact the project from meetings this Vision.
n Put those risks in the Risk Register and connect them to Features and Capabilities to assure they are mitigated during development.
n Documenting the risks, developing actionable plans to manage the risks and measuring the reduction of risk is simply good project management
n The product roadmap provides a visual overview of the project's requirements and priorities.
n This visual overview allows the project team to quickly identify gaps in requirements and incorrectly prioritized requirements.
n For each element of the Product Roadmap, ask and answer what could possibly go wrong and what actions can be taken to reduce this probability of unfavorable impacts.
n For each delivered Capability, capture the risks in the Risk Register, the probability of occurrence, and the mitigation work at the development level
n The Product Backlog is a tool for accommodating change within the project.
n Being able to add changes to the Product Backlog and reprioritize requirements regularly helps turn the traditional risk associated with scope changes into a way to create a better product.
n Keeping the requirements and the priorities on the Product Backlog current helps ensure that the development team works on the most important requirements at the right time.
n Define work in the PBL to but down risks in the Risk Register.
n During each daily Scrum, development team members discuss roadblocks or impediments that may be or become risks to the project.
n Talking about roadblocks every day gives the development team and the Scrum master the chance to mitigate those risks immediately.
n Documenting these roadblocks, capturing actual risks in a risk register, and tracking the management of the risks increases the probability of success
n The Scrum team discusses issues with the past sprint and identifies which of those issues may be risks in future sprints.
n The development team needs to determine ways to prevent those risks from becoming problems again.
n Revisiting the Risk Register during the retrospectives at assure nothing was missed, risk reduction occurred as planned, and no new risk have appeared during the Sprint.
n A risk owner is the person who is responsible for monitoring their risks and executing risk responses when appropriate. Risk owners often aid in defining the risk response plans and in performing qualitative risk analysis and the quantitative risk analysis for their risks.
n When identifying risk owners, consider the following criteria:n Who best understands the causes, the risk, and the impact?
n When risk owners develop risk response plans, they may fail to consider secondary risks, risks that arise as a direct result of implementing a risk response.
n Good project managers educate and ask risk owners to identify and plan for significant secondary risks.
n Risks include positive events or conditions, that if they occur, cause a positive impact on the project goals.
n Therefore, many project managers fail to identify these positive events and miss the opportunities that could save the project or enhance the project’s value.
n Aleatory Uncertainty, which is irreducible and can only be addressed with margin or reserves
n Epistemic Uncertainty, which comes from lack of knowledge (epistemology is the study of knowledge) and can be addressed with redundancy, experiments, prototypes, and other knowledge gaining processes
n Risk Management is How Adults Manage Projects ‒ Tim Lister
n Agile development process participate in risk management, but agile development processes are not Risk Management