Identifying Risk in Scrum Projects
In modern management frameworks like Scrum, there is a tendency to avoid formal risk management, given that Scrum principles already cover it. Adherents of Scrum think that project success is guaranteed if you have short iterations, concentration on working software, test automation, delivery of small increments on each sprint, and frequent customer feedback on each small feature. The daily scrum serves as an informal risk or issue identifying activity because, during this meeting, each member of the development team answers the question “What‘s blocking you?”.
However, let’s imagine that every day half of the team members report blockers. This means, instead of concentrating on their main tasks, the team and the ScrumMaster are working to resolve unexpected impediments. This is very disruptive to the project, and soon the team will be thrown off course. That’s why early risk identification is important for all types and sizes of projects; it helps Scrum teams plan their sprints better since they know what risks they might face.
Common Risk Assessment Techniques
There are many techniques you can use to identify risks. Companies that have a long and storied project history can use techniques like interviews, documented knowledge, risk lists, or expert judgments. Here, caution must be exercised when using any subjective knowledge-based information to ensure it is relevant and applicable to your situation or project.
You can also try different diagramming techniques, like the Ishikawa or Fishbone Diagram, also known as the Cause and Effect Diagram. Applying this method in the risk identification phase is quite complex since you need to have an initial list of risks collected in advance. It makes much more sense to use this technique when you are trying to resolve an existing problem by finding its root cause. In Scrum, this can be more easily done at a sprint retrospective meeting, to find out the real root of existing issues or problems, and to permanently resolve it.
Another common approach from the list of risk identification techniques is the Nominal Groups Technique (NGT). It assumes that only some of the project team members will attend the meeting, and thus reduces the brainstorming “chaos”. With NGT, you invite only those who can best identify project risks.
NGT is a good technique, but its greatest drawback is the fact that only a subset of the team is involved. In Scrum, development team members are cross-functional, so we cannot exclude team members assuming that their interests are already represented by someone else.
Identifying Risk with Brainstorming
Using brainstorming as a risk identification technique provides a free and open approach that encourages everyone to participate. For a session to be effective, it’s recommended that you have a defined project scope and that it happens before the first sprint planning. It’s much less effective to organize the session later, since you may lose the chance to avoid some problems early on.
Picking a Facilitator
The best-suited candidate for the brainstorming session facilitator is the ScrumMaster. Usually, this person is already a skilled facilitator, as this is a part of the desired ScrumMaster skill set. Sometimes companies invite external consultants specialized in brainstorming facilitation because a badly managed brainstorming session is an expensive waste of time and can jeopardize the success of the project. Having an external facilitator will also give a chance to the ScrumMaster (or project manager) to participate in the session as a general member and bring his/her ideas to the table.
Role of the Facilitator
The facilitator’s main role is to be a note-taker during the session, capturing the ideas that are raised (this article can be helpful for effective note-taking, and you can use tools like this one for online note-taking). In addition, the ScrumMaster will need to keep the group discussion on track, ensure everyone is heard, and manage the meeting time. The results can be recorded on a whiteboard (take a picture!) or flip charts. If using online tools, learn them ahead of time, so you don’t spend precious meeting time on figuring it out.
Determining Who Should Attend
The meeting is for the full Scrum team, so the product owner, development team, and the ScrumMaster are invited and encouraged to attend the meeting. Having the entire team participate in risk identification is helpful because it can result in a greater sense of project risk ownership, and a team commitment to managing risk for the duration of the project.
You can also consider inviting other stakeholders from the client/business side, but try to limit it to the key parties with a vested interest (eg. those with key responsibilities or interest in critical technologies and any commercial considerations). Another reason to have participants from different areas is that if there are only Scrum team members in brainstorming, then they will focus on items in their ‘comfort zone’, or their control, such as technical risks, ignoring other important areas such as commercial or external risks. Remember: if key stakeholder perspectives are not represented, important risks may be missed.
A brainstorming session can also serve as a knowledge and interest sharing session. Since this session will have a broad cross-section of project roles and viewpoints it’s a great opportunity for participants to share perspectives on different areas of the project. At the end of the session, everyone will have a more complete understanding of the project, its complexities, and its risks.
Prepping Attendees for the Meeting
Group brainstorming can serve as a great team and customer relationship building activity to kick off a project. Don’t underestimate using a session warm-up exercise that may make the team more comfortable with bringing forward ideas later in the session. However, be cautious with selecting the warming-up game, since the participants from the other companies or teams may not value it in the same way.
When prepping attendees for the meeting, one big time saver is helping everyone understand the distinction between the three aspects of risk: the cause, the risk itself and the effect. Often attendees have issues distinguishing between the three, so having clarification before the meeting starts will bring more focus to the session.
The introduction part should also present the brainstorming rules to the participants. They can be found here, and it helps to have them visualized in the meeting room as well (if possible, write them on a board). If the meeting has remote participants, you may want to email them the rules along with the invitation to the meeting and ask them to read the rules before the session. This will save some time during the brainstorming session.
Running a Brainstorming Session
The “brainstorming magic” happens in this session as the Scrum team members verbally identify risks in turn. If a raised risk sparks a new idea for someone out of turn, they can take notes so as to not forget an idea before their turn. In the next round of risk identification, this new risk can be added to the list. The round table iterations are repeated as many times as new risks are identified by the team. Recording the session for reference later can be very helpful. All the attendees must get a chance to talk, and all the ideas must be captured during the brainstorming session.
At this stage of the brainstorming session, it’s the quantity of the identified risks, not quality, that’s important. The quality is addressed later, during a risk assessment session. No criticism or discussion is expected during the brainstorming session because that would discourage free and open participation. This is important because risks can be triggered in a chain. A small risk can become fuel for the discovery of a much larger risk.
It’s also important to note that when discussing risks, we must keep in mind that they can affect project objectives both negatively and positively. During the brainstorming session, both types must be identified, although they are treated differently – negatives as threats and positives as opportunities.
Setting a Time Limit
Timebox the risk identification meeting; it should be no longer than two hours. It is a good idea to have a short break in the middle of the session, to give the participants’ brains a rest. Even if the project scope is very large, it is still suggested to have a hard stop after two hours. But it also should not be too short that the participants were stopped because of the timeboxing in the middle of the warm brainstorming activity. Ideally, the session should end when there are no new risks identified by the team. For mid-size projects, one and half hours is an optimistic duration to be used (including introduction, session, and the conclusion part of the activity). For this duration, no break is needed in the middle.
Narrowing Down the List
Risk management is an iterative process. After the initial list of risks is identified at the beginning of the project, the team can update the risk register at each sprint planning meeting later on by allocating time during those meetings. From a participant’s perspective, he should feel that the team has accomplished something during the risk identification session and that it has not been a waste of time. At the end of the meeting, the facilitator should conclude the meeting by sharing next steps with the participants.
So, what’s next?
The Brainstorming session which serves only for risk identification is over. Now, the facilitator needs to categorize, group, and connect the random ideas to analyze the results. The scrubbed/organized risk list should be presented to the team as an output of the brainstorming session, during a separate risk assessment session. After the assessment, the risks can be evaluated based on their impact on project objectives and their probability of occurrence as described here. For the highest priority risks, mitigation plans should be developed. The key idea here is to keep the initially identified list of risks up to date by reviewing it at each sprint planning session. In addition, while the project is running, with the assessed risks, the Scrum team can use a risk burn-down chart described in this article as a technique to follow up with the risks on each sprint.
To learn more about effective brainstorming, check out articles like this one or this one or even this one! As Albert Einstein says: “A ship is always safe at the shore – but that is NOT what it is built for.” Identify your project risks with brainstorming ahead, and enjoy smooth sailing!
Insights delivered to your inbox
Subscribe to get the latest insights in IoT, digital health, and connected products.