Usually in an agile process such as scrum we don't do an initial analysis as in waterfall model. How to identify project risk in agile process.
I disagree with the statement,that in SCRUM risk analysis is not done upfront
What about --
Risk analysis when a story is groomed & estimated during SPRINT plannnig --->
Considering & factoring in risks ( and considering mitigation - new stories ?? , "story is too big and risk -- break it down " , "no test to catch regression -- can not committ to this story unless regression tests are written " etc etc ) when story is groomed ?
Considering & factoring in risks when story points are being estimated ?
I do not think one is implementing SCRUM properly if formal risk analysis is not part of the SPRINT planning process ! I would be very nervous as a PM,if risks are not analysed,discussed and mitigations proposed before committing a story to the board
No matter what development methodology you are using there are a number of risks that can be known up front. These need to be identified and mitigated. During the project it is likely additional risks will be identified.
Many of the risks are fairly standard, and have known solutions. Identifying them and putting mitigating practices in places is important. Here a list of some of the risks you may want to consider.
- Web design has a number of risks including SQL injection, insecure logins, cross-site scripting and others. See SANS: CWD/SANS TOP 25 Most Dangerous Software Errors for some examples.
- Cyber security risks, see SANS: The Top Cyber Security Risks and SANS: Top 20 Internet Security Problems for some details.
- Failure to adequately secure payment data. Compliance with Payment Card Industry Data Security Standard is a starting point.
There are additional project specific risk which need to be dealt with on a per project basis. These include:
- Technical risk in implementing new functionality.
- Staffing/skills risk for the team. The team may not have all the skills it needs. You may have a limited number of team members with a critical skill. Agile may make it easy to develop and/or transfer skills.
- The risk of missed or unnecessary requirements. Agile may help mitigate this risk.
- Scope creap risk (additional out of scope requirements added during the project). Agile may help accommodate/deal with the problem.
The problem isn't that risk management is not done upfront in Agile software development processes. The problem is that risk management is not done explicitly, that is, risk management is implied in Agile processes so teams don't have the same notion of risk management as traditional project management expects. This is not to say that explicit risk management and agile cannot work together.
The SEI's Continuous Risk Management paradigm fits very well with agile processes. The best way I know to combine CRM with Agile is to perform a "mini" Software Risk Evaluation workshop using the SEI's risk taxonomy-based questionnaire as a guide. Mini-SRE's take anywhere from a few hours to a day to complete and not only teach a team what they need to know to identify and manage risks but also creates the initial risk backlog necessary to move forward with other parts of Agile processes. Such a workshop should happen during Sprint 0 and act as a guide for helping the customer decide which things to work on first, and other non-development things the team should be working on.
I agree Scrum doesn't explicitly talk about risk assessment as Waterfall does.
There are however a number of opportunities to handle risk within the scrum framework. Starting with the backlog refinement exercise. I like to use BDD for this part, and where areas are particularly complex use a 3 amigos format to understand the right approach.
This way most of the risks are identified prior to sprint planning. Even if risks are discovered during sprint planning or even during the sprint, Scrum allows for rethinking sprint goals and putting stories back on the backlog for more refinement.
Backlog refinement effectively houses the analysis and prioritisation work in a more iterative fashion that the upfront analysis that is seen in waterfall.
So you see, risk management and deep analysis is present but done on smaller chunks of work as other area of functionality are progressed.
This does lead to some "evolutionary" solution design as things can emerge that lead to changes in existing implementation so there is a trade off between momentum and analysis paralysis.
Depends on what you are building, but most people prefer momentum.
Due to the nature of agile methodologies, risks are not identified at the very start, as in the waterfall model, instead risk identification and mitigation take place throughout the process. As they are so incorporated in the ceremonies you undertake in agile, such as the daily scrum, risk analysis might not appear to you as taking place. This is of course what makes the agile method so much more adaptable than the waterfall method.
In terms of risks, there are risks which can be identified as general risks across any projects you undertake, while other risks are more specific to the project itself. It is the latter which are identified and reduced so well when using agile.
"Agile" is a set of values and principles, not a framework. Therefore, I'll address myself specifically to the Scrum framework as a reasonable baseline, with the understanding that other agile frameworks often leverage Scrum or contain similar approaches that are at least comparable.
Project risk and risk management is not excluded from any agile methodology. There's just usually no explicit requirement for a separate risk register, or a mandate for risk-related items on the Product Backlog. That said, the principles and theory behind frameworks like Scrum make risk management an ongoing activity that is part of numerous events and artifacts, so you just need to reframe how you look at risk management in an agile context.
Scrum Leverages Emergent Design and Just-in-Time Planning for Risk Management
The notion of an up-front risk register is that you've already defined all the work, and therefore know all the potential risks. This is usually fallacious in practice, but it's still the basis for assuming you can do an up front risk register at all.
Agile frameworks like Scrum are based on just-in-time planning and emergent design. The framework specifically says:
The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk.
In addition, the Product Backlog is often an implicit source of risk tracking, which can be made explicit by making it a domain attribute that is included in Product Backlog Items.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The key take-away is that risks are often identified during Backlog Refinement, Sprint Planning, story spikes, Sprint Retrospectives, and other activities within Scrum. For example:
- The Product Backlog item for feature Foo can define known risks, and reflect them in whatever way the Product Owner and the rest of Scrum Team consider useful.
- Risks should be refined as part of the general refinement process during the Backlog Refinement event.
- During Sprint Planning, the risks associated with Product Backlog item Foo should be identified as part of the estimation process if they're not already identified within the Product Backlog itself since the risks will likely impact the level-of-effort for the work item and uncover tasks and story spikes needed to address those risks during the upcoming Sprint.
- Risks identified during the Sprint should be addressed during the Daily Scrum, and additional conversations to address those risks should be coordinated and reflected on the Sprint Backlog.
- Unexpected or previously-unknown risks that impact the Sprint Goal should be urgent items raised within the Sprint to the whole Scrum Team.
- Identified risks should become discussion points within the Sprint Review, and perhaps addressed through refinements to the Definition of Done when necessary.
In other words, it's not that risks aren't addressed. They are simply addressed all the time throughout the process. The main difference with more traditional methodologies is that risk management is part of the ongoing framework and continuous improvement processes, rather than a one-time or up-front activity. In addition, since Scrum is iterative, emergent, and focuses on just-in-time planning, risks are generally addressed at the last responsible moment rather than all at once. There are many reasons for this, but the biggest is that one core principle of agile frameworks is optimizing away unnecessary work:
Simplicity--the art of maximizing the amount of work not done--is essential.
Addressing risks that may never come into scope, or that may be resolved or obviated before they impact the project in any way, is a key benefit of agility. In simpler terms, not spending time identifying risks that don't (yet, or possibly ever) need to be identified or managed is a waste of time, and Scrum specifically optimizes that away by promoting a just-in-time approach to risk management.
All agile methodologies, especially scrum has core principles and values that if followed duly will mitigate future risks. The iterative approach and transparency will help in realizing any risk associated with the project. One of Scrum ceremonies, which is Daily Stand-up helps in realizing any escalation or possible risks that may result from this. In Summary, Agile Methodologies if adopted will mitigate risks in your project.