Managing risk in an IT project – Risk in Scrum

Managing risk in Scrum

In the Scrum Guide, which is the main source of knowledge about the methodology basics, the term ‘risk’ appears only three times.

The first time, when the authors underline that the iterative approach to project implementation, that is, work in sprints, helps to optimize the risk. The second — when they refer to the sprint length. If it is more than one month, then the risk increases because long-term planning does not allow responding to changes flexibly enough. And the last time, the risk is mentioned within the context of Scrum artifacts: the lack of transparency threatens project implementation.

I fully agree with this risk recognition. Not only the Scrum Guide, but also other publications associated with this methodology point out risk management as an essential component of the operating in the iterative approach. This means that potential risks are monitored regularly during sprint planning, daily stand-ups, sprint review, and retro, and when a threat appears, it is included in the sprint backlog or the product backlog.

What does Scrum not cover?

So can we consider that following the rules is enough?

In my opinion, not exactly. Scrum — which is not obvious for everyone — is not a project management methodology, but a teamwork style in the agile environment. The role of Scrum is not naming everything that is related to the project and what might happen in it. It is enough to list the areas not covered in the Scrum Guide, for example, procurement and budget management. In the case of a risk, the fact it is described in the Scrum Guide, and many other publications, may lead to a wrong conclusion, the subject is exhausted.

Of course, by following simple Scrum rules, it is possible to avoid many risks, but not all of them. When carrying out a project, there are types of risk and circumstances that are not only unidentified by the team, but also not added to the product backlog.

During the meetings in the Scrum process, the development team and stakeholders deal with  risk identification, but as the practice proves, usually they relate to technologies, dependencies between requirements, time, maintenance costs, or requirements efinement.

These are absolutely critical aspects of the project, however, do we think of higher-level risks during the meetings? Financing of the project in the following year, the legality of solutions, general rules of the company management, market threats such as competition or new regulations — these are just a few of them.

Even if we will take the above-mentioned risks into account, what can we really do to prevent them? On the one hand, we cannot just put in the product backlog a risk that reads: “In 3 months we may exceed the budget.”

On the other, what about apparently minor factors such as software licenses, scheduled holidays, the approach of the particular decisive people to a specific solution? In these areas, there may also happen something that will put into a question the product’s final success.

Some of the people may say: “Yes, we take all of that into consideration every time.”  If that is true, congratulations to them. I admit, I do not always succeed. Also the Scrum Guide, in the section dealing with sprint review, recommends focusing on a broader aspect of the product instead of cases closely associated with current work.

I treat this as one of the many areas left to the Scrum team so they can plan on their own how to cope with those factors.

In my opinion, an extensive analysis of risks, which can have a huge influence on the project as presented in the examples above, is highly important. However, during the Scrum meetings, it is often ineffective because the participants focus on the micro-scale, which is the present and the upcoming sprint. Then, they lose sight of other threats, and they are unable to estimate the size of the risk entirely.

I am also afraid that the development team would be moderately interested in discussing many mentioned cases, and sometimes it would not even have enough competencies to do so. Whereas, inviting ever new external experts to the meetings may result in losing the focus on the product’s development, too extensive debate, and overall discouragement from such meetings.

Summary

Apparently, even an agile project requires additional actions for risk management. And though the iterative approach is beneficial, certain automation and the natural order of activities occurring one after another in the cycle of product delivery may cause that various risk categories will be unnoticed. In turn, this may lead to a false sense of control over the project.

In the following article of this series, I will discuss several simple ways to detect threats in a project. I will focus on the solutions useful in less complicated projects, when we do not want to spend too much time contemplating risk, as well as on those solutions that will prove themselves in more complex projects carried out in a corporate environment, where we need to take into account many more factors than just those arising directly from the project.