Risk Planning & Management in Agile/Scrum

Scope Risks:

Risk involved in expanding the requirements (scope creep).
Managing frequent changes in requirements without affecting the project timeline or budget.

Technology Risks:

Failure of the technology used in the project.
Obsolescence or lack of support for software protocols.
Hardware failures.
Lack of scalability.
Insufficient technological understanding by the development teams.

Customer/Stakeholder Risks:

Customers or stakeholders not providing required materials or information on time.
Misalignment between stakeholder expectations and project outcomes.
Stakeholders frequently change priorities.
Inadequate stakeholder engagement or support.

Personal Risks:

Risks posed by individual developers, such as lack of necessary skills.
Conflicts between team members.
Communication issues, such as groupthink.
High turnover rates or unavailability of key personnel.

Schedule Risks:

Underestimating the time required to complete tasks.
Delays in starting or completing sprints.
Inaccurate sprint planning and backlog estimation.

Quality Risks:

Compromising on quality to meet tight deadlines.
Inadequate testing or QA processes.
Defects and bugs slipping into production.

Resource Risks:

Inadequate resources (e.g., personnel, tools, infrastructure).
Overcommitment of team members leading to burnout.
Dependency on third-party vendors or services.

Process Risks:

Deviations from Agile principles and practices.
Inconsistent or improper implementation of SCRUM ceremonies.
Lack of proper documentation.

Financial Risks:

Budget overruns.
Inadequate funding or changes in financial support during the project.

Compliance and Legal Risks:

Failing to adhere to industry regulations and standards.
Potential legal issues arising from non-compliance.

Market Risks:

Changes in market conditions that could affect the project’s relevance or success.
Competitors releasing similar products earlier.

External Risks:

Unforeseen external factors such as economic downturns, political instability, or natural disasters.
Changes in supplier or vendor conditions affecting the project.

Risk Assessment

Risks represent potential ways in which your product could fail.
Risk assessment via impact vs likelihood metrics is used to prioritize risks.

Impact Vs Likelihood matrix is a 2D representation of the amount of influence a risk has on the project.

What is a Risk Plan? How to implement?

Start with project risk plan definition.
A project risk plan is a collection of risks and actions you can take based on indicators and risks categories.

A Risk Plan

List of potential project risks
Their impacts and likelihoods
PLanned actions on how to address these risks if it comes up.

Risk Management Plan

Risk ID
Risk Description
Category (Risk Priority)
Risk Indicator
Action Plan

Risk Mitigation

Accept Risks
Avoid Risks
Transfer Risks
Reduce Risks

We must understand the impact and probability of each of those risks to assess:

Kind of response
Who should own the risks
What time lines.

Risk Anti Patterns

Some risks are so common that they create predictable patterns in the projects.
Antipatterns are defined as commonly occurring solutions in a project that cause negative consequences such as project failure.
The bestway to avoid antipatterns is to understand them so they can be identified and addressed.

Group Anti Patterns

Anti Patterns	Nature of Issue	How to Resolve?
Analysis Paralysis	Where developers get stuck or stalled in one phase of the project, usually from analyzing requirements leading to paralysis of the project.This happens in the specification phase of the project.The stakeholders spend a lot of time analyzing requirements and cannot decide on project direction.	Run a project in small releases as prescribed by Agile and scrum with incremental releases
Carts before the HorseCart before the horse	Putting things in the counter productive order. This means putting too much emphasis on the project part that should be done later. Eg. If in a limited time and resource scenario, if more resources is allocated to build a relatively insignificant feature instead of a critical one.	The developers should clearly understand the priorities of the development and stay focused on those priorities.
Groupthink	How people tend to follow the general opinions of a group regardless of whether or not their own opinion are different. Groupthink can lead to poor decisions and judgment in the project development.Most common example of groupthink is in group discussion on a project. When ideas tend to come from only 1 or 2 people in a meeting, while most other members are quiet and go along with suggestions.	Remember that conflicts can be a good in a group discussion if done constructively.Creating an open atmosphere of discussion where different perspectives are encouraged is very helpful in combating groupthink.Generate solutions to problems silently, as in lean software design. This means allowing teams to break up into smaller groups of individuals and encouraging these small groups to come up with a different design and alternatives. These suggestions are then combined, and this approach has the benefits of not pulling people on the spot.
Silos	A team separated into smaller groups can be a good strategy, particularly if a specialized group can create more effective work. But this then can run the risk of teams losing touch with each other and limiting communication.Silos are created when a lack of communication among a group of developers occurs. It leads to loss of unified focus and creation of counterproductive strategies & features.Features developed in silos are developed in vacuum, so the work of one team could be incompatible with that from another team.	Encourage an open and positive atmosphere where team communication and collaboration are favored.Re-examining the management structure could also be beneficial if there is a flat management where developers can speak directly to one developer. Communication can flow easier and bureaucracy can be avoided in both cases.
Vendor Lock In	When a developers create a product that relies heavily on a single technology solution or vendor. Vendor lock in is different from choosing technology because it is the best option, but rather it generally involves a lack of flexibility in moving to another technology without substantial costs.The heavy reliance on a single technology as a product moves forward is problematic.If the technology cannot cover what is needed, become outdated, or cannot adapt to a change.	It is important to research before committing to a technology or a solution.
Overengineering	It occurs when a product is made more complex than necessary, such as when extra or needless features are added to the product, making it confusing for the majority of users.Overengineering can happen on both the user interface of a product or in its internal processes.	Developers should clearly understand the needs of a product. What the product needs to be able to do versus the wants of a product.What would be nice if the product could do, but it’s not necessary for success.
Gold Plating	It occurs when much effort is put into one part that it reaches a point of diminishing returnsSo much extra effort is focused on a part of the project that no longer contributes value to the product.This usually occurs when developers add extra features to the product to impress the client, particularly when the team finishes early.However, adding features can add unpredicted extra work to a project.The user requirements should be specified by the client and not by developers, and this can make the client disappointed and confused about the end product.	To avoid gold plating, the developers should stop working when the product functions well.If the team feels the new features should be added, the features must first be reviewed with the client.It’s a good question to ask when considering adding extra features include.Does this feature improve the product?Does this feature make the product confusing somehow?Does this feature take away from the main functionality?Another solution to avoid gold plating could be conducting a user study. A user study involves taking a small sample of users and asking them to try out a new features on a product and provide feedback.
Viewgraph Engineering	Occurs when too little effort is put into project. It is the opposite of the gold plating in that way. Viewgraph engineering is working on what is not important.Viewgraph engineering is more directly tied to management practices and how those practices can make project work difficult for developers by requiring them to work on things other than development work such as unneeded documentation and reports or creating presentations.	Agile methods purposefully seek to avoid Viewgraph engineering by placing focus on creating work software over comprehensive documentation.Creating a basic prototype is often more informative than any report on presentation, so time spent on such documentation may be better served in development. If the prototype is good, then it can be built upon.
Fire drill and heroics	Fire drill happen when developers do very little work throughout most of the project and then make a big push toward the end of the project, resulting in overtime work to meet deadlines.This leads to loss of quality in favor of producing a product quickly.Fire drills can have many causes, including bad management practices or developers wasting time.Expectations were not properly established with the client.Fire drills can also lead to heroics.Heroics is an anti-pattern where the developers end up relying on only one person with technical skills to get the project done. This requires that one developer have almost superhuman skills as he or she takes on almost the entire project.	It is important to establish expectations with the client early on the project and to follow Agile software development practices, for example, using time boxes, always producing a work product at the end of those time boxes.These strategies keep the team working at a steady pace, avoiding both the fire drills and heroics.
Dead March	This happens when developers and management are at odds because the management team is enforcing a path for the project that developers do not believe in. This leads the developers to lose conviction and passion for the project, which increases the likelihood of project failure.Despite this, everyone keeps working out of a sense of obligation. In these cases, the developer morale is low, then the quality of the product will suffer.	It is important for management to maintain open – communication with developers.Managers should listen to what the team thinks about the direction of the project and be willing to explore other alternatives in project development.In some cases, simply reassuring the developers that you understand and recognize their concerns is all that’s needed to avoid a deathmatch.

Individual Anti Patterns:

Issue	Nature	How to Avoid?
Micro-Management	It occurs when a manager is very controlling and wants to be involved in every detail of a project, no matter how small.It demonstrates a lack of trust in the developers which affects team morale and product quality.This can also become worse if the team is blamed for the manager’s behavior.Micro managers in general do not micromanage to bring down developers morale. Instead, they usually think that the project will fall apart without them.It can also be caused by overly ambitious timelines, poor product quality or fear that developers are not up to the job.	In general, micro managers themselves have to provide a solution. Micro manager has to admit their behavior is affecting the team and will be willing to take steps towards improving their behavior. Further management training may be needed before micro managers can adjust their actions. It is worth noting that wanting to stay informed on the project progress should not be confused with micromanagement asking for short daily meetings. Updating project progress is actually a good agile practices
SeaGull management	SeaGull management is an individual antipattern that happens when a manager is only present when problems arise or right before deadlines.This results in otherwise absent managers swooping in, dumping a lot of information or requesting on a developer’s and then disappearing again.This can cause a lot of stress for the team and can easily push project into a fire drill project.And further, the developers will be working in constant fear of when the next dump will be.The behavior of a seagull manager is usually caused by several factors – busy schedules, inadequate planning or stress.	In general, if you suspect you might be a seagull manager, it is a good idea to re-evaluate your schedule and how you interact with your developers.
Primary means of communication	The method of communication used between managers & developers can impact a project.Email in particular lends itself to creating a single manager who only writes to the team with large workloads or big dumps of information and does not communicate frequently otherwise.Further, email is often not the best way for the team to communicate well with managers because it can be difficult to provide the context in emails or information can be easily misunderstood.Emails can also be too formal for most communications.	Managers and developers must take time to communicate in person. When that is not possible, other means of communication, such as chat service, video conferencing and phone calls are a good alternative to email.All of these forms of communication have the added benefits of giving respect and attention to the team members, which helps to increase team motivation.
Loose cannon	Loose cannon refers to an unpredictable person or thing who can negatively affect others unless it’s managed somehow.Loose cannons tend to be people who make significant project decisions without consulting the rest of the team.This behavior is reckless and can create more work on other group members.A loose cannon is not to be confused with someone who asserts their opinion on every topic leading to poor project decisions.	Often dealing with loose cannons involves understanding the motivation of the individual’s behavior.Are they trying to cause trouble?Are they trying to prove their work to the team?Once this is understood, a manager or team can try and get the individual to understand that their behavior is destructive and encourage the individuals to take steps to change it.In some cases, organizational steps might be necessary to address the problem.
Intellectual violence	Intellectual violence concerns a person who asserts their opinion on every topic and impedes progress by questioning every decision and action, or using their advanced knowledge in an area to intimidate or look down on other team members.These individuals tend to repeat their opinions so much that the rest of the group accept them just to avoid confrontation.That affects open communication and productivity.So loose cannons are sometimes the cause of intellectual violence.	If the developers cannot solve this impediment by themselves, then the Scrum master can try talking to the individual in private about his or her behavior and suggest any appropriate changes.Alternatively, the Scrum master can encourage an open discussion policy, for example, reinforcing the idea that there is no such thing as a stupid question and discourage pre-judging opinion or inexperience.

What is a contingency plan and what is the fallback plan?

In short, they describe every action that you will take if the risk is about to happen or has happened.
So please note that this plan is developed to manage identified risks only.
A real world example of a contingency plan – You’re working on a construction project and there is a risk that rain may fall during your project execution, which will damage your consumables lying out in the open.
Therefore, you make a plan that says if there is an indication of rainfall, all consumables will be covered with a plastic sheet.
You further add that after the rain stops, you will bring a blower or vacuum pump to clean and dry the wet consumables. And this is the simple contingency plan for this risk event.

Fallback plan

A fallback plan is implemented when the contingency plan fails or it’s not fully effective.
In other words, you can say that the fallback plan is generally made for residual risks.
It is a backup plan for your contingency plan.
The fallback plan defines the cases where actions have to be taken for real.
Suppose the rain continued to fall for a very long time. Longer that you anticipated, which causes the consumables to be not usable anymore. In this case, you will implement your fallback plan, which you already had planned. So your fallback plan says that if the rain continues to fall for a very long time, causing consumables to be damaged, you will reorder consumables from a pre-identified supplier and start the work.

Risk Assessment Meeting

The team uses this meeting to determine the probability and impact of each risk.
Determine if the risk can or should be avoided by making changes to the project plan and appropriate response and catalog risk and responses in the risk plan.
The risk assessment meeting should be a meeting usually conducted during the sprint planning process.
However, you can talk about risk in other scream scrum events like, for example, product backlog refinement. And this is an excellent opportunity for the Scrum team to include a discussion about risks.
- Which item is risky and yet still valuable?
- Which element is risky and does not bring significant value?
- Is it worth keeping it on the product backlog?
- What experiments do we need to run to validate our assumptions?
So keep in mind that the risk management in Agile and Scrum needs to be done at two levels: the project level and the sprint level.
So the project level risk management process is done at the broader level, taking into consideration the whole project and its requirements.
Sprint level risk management process is done at sprint level, encompassing details of the sprint.

Risk Planning

Identifying Risks
Marking on Impact and possibility
Setting the contingency plans

Monitoring Risks

Who should manage the risk?

Everyone in the SCRUM team should manage the risks.

When should the risk plan be created?

Risk management must happen during the sprint planning.
However, it can be discussed during Product Backlog refinement.
Daily Scrum, Sprint Review, Sprint Retrospectives.

Risk Management Plan Vs a Risk Register

Risk Management Plan details, the Risks, severity & contingency plan.
A risk register is a document detailing all these together in a single page.
Risk Management plan is tailored to a specific project, but the risk register can be used for varying projects.

ROAM – Risk Management in Agile Projects

In some contexts, particularly within agile project management frameworks like SAFe (Scaled Agile Framework), ROAM stands for Resolved, Owned, Accepted, and Mitigated. This version of ROAM is used to categorize and manage risks during risk management workshops or sessions. Here’s what each term means in this context:

Resolved: The risk has been addressed and is no longer a threat to the project. The necessary actions have been taken to eliminate the risk.
Owned: A specific individual or team has taken responsibility for managing the risk. They will monitor the risk and take appropriate actions to mitigate or resolve it.
Accepted: The risk is acknowledged, and the team has decided to accept it without taking immediate action, often because the cost or effort to mitigate it is higher than the potential impact of the risk itself.
Mitigated: Actions have been taken to reduce the impact or likelihood of the risk. The risk still exists but has been lessened to a more acceptable level.

This ROAMing process helps teams systematically address and manage risks, ensuring that they are actively handled rather than ignored. It provides clarity on the status of each risk and ensures accountability within the team.

Certificates

16. Risk Management

Category	Definition
High Priority Risks	These are the items which ran high. They need immediate mitigation.
Medium Priority Risks	These are risks you should be concerned about but you don’t need to do anything right now. But there should be a risk plan and strategy on how to deal with that when it occurs.
Low Priority Risks	These are risks that isn’t something that concerns your project, but should still be kept on notice.