Agile risk management – do we need it?
- Part of the business community has apparently simply dropped the systematic consideration of risks with the switch to agile approaches, which works well for some, but is certainly also often responsible for the “mindless agile chaos”, which representatives of the old way of working criticise, not always without good reason.
- The rest seem to try to simply impose classic risk management on their agile approaches. Unfortunately, many things that are part of everyday life in agile projects are considered risks according to classical thinking – such as ongoing changes to the scope. This contradiction is either resolved by carrying out the project in the classic way with iterations and thus giving away the advantage of agile methods, or the different parts of the project organisation are left in open conflict with each other and have to deal with the resulting problems.
My opinion is that this has to be done better. We can call the new approach “agile risk management”, but I am not happy with this term – on the one hand, we want to get away from the narrow concept of “risk”, on the other hand, risks do not want to be “managed”, but addressed. I want to describe an approach here that does both, knowing that sooner or later we should look for a slightly less misleading term for it.
What is risk?
Following Gerhard Wohland, I want to distinguish here between danger and risk. Dangers are environmental events that can have negative effects on us. So a speeding car is a danger. A risk, on the other hand, has to do with one’s own actions – when I cross a road, I take a risk. Falling rocks in the mountains is an objective danger – going hiking in the mountains is a risky activity.
Wohland writes: “Since non-decision-making also involves risk, risk cannot be avoided”.1
He goes on to say that with increasing complexity, fewer and fewer negative events can be clearly attributed to external environmental influences. Our actions have an impact on our environment, and the greater the complexity of the situation, the greater the probability that we ourselves will trigger undesirable events that we cannot foresee in advance. Higher complexity therefore means an increase in risk, even if the objective dangers remain the same.
As everywhere else, the bigger problem here compared to the known risks are the “unknown unknowns” – nasty surprises we will experience that we don’t know we don’t know. By the end of 2019, how many risk management reports do you think will have listed the possibility of a global viral pandemic as a threat to the organisation?
Problems with risk management
In classical projects, risk management is often seen as a separate task in the functional division – either as part of project management, or, in larger projects, as a separate function working to the actual project management or “steering” body.
This structural decision alone leads to a number of problems. Obviously, in a highly specialised work environment, neither recognising nor investigating nor addressing a risk can be separated from the actual technical work. No one except the specialists is able to address the risks of their work – often not even to understand them.
They try anyway, which in practice means that risk management quickly becomes unpopular on all sides:
- With the experts, because discussing risks with people from outside the field costs a lot of time and nerves,
- with the decision-makers, because they naturally feel that the understanding of the risks in the risk assessment is superficial at best,
- furthermore, because difficult decisions then have to be made with an inadequate level of information,
- finally, again with the technical experts, who in the end have to implement the resulting measures and know very well that these have usually been decided with an expandable level of expertise.
The fact that this approach is risky in itself was impressively demonstrated during the construction of the BER airport.
Another unfavourable side effect of functional separation is overengineering. Since addressing the risks cannot be done within the framework of the role alone, available time is instead used to expand the “management” aspect. A variety of budget-filling activities can be developed here, from calculating probabilities of occurrence, to determining acceptable risk ceilings, to developing, collecting and monitoring metrics, to reporting to third parties, to recursively applying them to themselves, for example by developing risk management standards to manage the risk of unprofessional risk management. How much of this actually benefits a client is debatable.
The end result often seems to be a state where project management has a list of potential problems lying around somewhere in the form of a long Excel spreadsheet with red-yellow-green colour coding, and where actually addressing risks loses out to their bureaucratic management. This is intransparent and ineffective, and it is not made much better by the fact that one can now use the cloud version of one’s favourite spreadsheet for this purpose.
For highly standardisable and routine processes such as series production or construction, classical risk management may nevertheless be a viable and perhaps even sensible procedure, but I do not want to presume a judgement on that. In agile, interdisciplinary teams at the latest, this procedure reaches its limits, which in my experience, as mentioned above, leads to many agile teams no longer consciously considering risk at all. Even if this is often associated with a lot of uncertainty and unpleasant surprises, especially for the customer, it seems to work at least so well that many companies are still willing to replace their classic process models with agile ones.
Implicit risk management in agile approaches
“Risk is the water in which the agile fish swims.” (Ron Jeffries2)
I still regularly encounter the reflex in organisations to react to increasing uncertainty and risk with more planning, more central management, more control. The result is inefficient, bloated, self-referential structures whose benefits can hardly justify their enormous consumption of resources. The perception seems to be that agile approaches can be afforded primarily in small, manageable projects, but not in larger or riskier ones, even though tools such as the Cynefin Model3 or the Blue-Red distinction4 suggest exactly the opposite.
In fact, in agile approaches, a certain risk management is already implicitly built in at the structural level, and this is done consciously, not by mistake. In the Scrum Guide, for example, the statement “Scrum employs an iterative, incremental approach to optimize predictability and to control risk”.5 Making risks controllable is therefore a core feature of agile methods, and the riskier a project is, the more important it is to apply agile principles in its implementation!
A productive team that continuously translates the highest value requirements into a usable, high quality product will deliver the maximum of what was possible within any given timeframe. As I understand it, you can’t make a delivery risk smaller. You can, however, make it bigger – through arbitrarily set deadlines, through long planning phases without concretely usable results, through poor prioritisation of tasks that do not always result in a maximally valuable, concretely usable intermediate result. And of course there is the possibility of increasing the potential for disappointment by means of unrealistic expectations about the scope of delivery.
This list can now be continued. What Scrum is for delivery risk, approaches like XP are for technical risk. Second-order communication roles, such as the Scrum Master, are tasked with finding and addressing communication and collaboration risks. Flow-based techniques such as Kanban aim to avoid inefficiencies, peak loads and other forms of waste, which must also be seen as a form of risk management. And so on, and so forth.
In sum, this means to me: a well-run, competent team that develops its product end-to-end in a user-driven way should have little need for risk management as we know it from the past.
But of course: we also want to look into the future. And the organisational reality is usually not as rosy as just sketched. There may be dependencies. There may be deadlines to which expectations are attached. Maybe the usefulness of the product does not increase linearly with its range of functions, but a certain minimum functionality must be achieved for it to really be called deliverable. And of course, even for teams in optimal environments, there are a variety of possible social, legal and organisational events that can affect the success of the project.
A new “risk management” for agile teams
If we want to avoid the weaknesses of classical risk management approaches and use the strengths of agile methods as much as possible, our approach to addressing risks should have some new characteristics.
To avoid waste and misunderstanding, we want the recognition, understanding and addressing of potential surprises to be done by the subject matter experts themselves. To mitigate risks in software development, we need software developers. To assess financial risks, it needs someone who is familiar with the finances of the project.
A dedicated “risk manager” role increases risk instead of decreasing it, because the additional person from outside the field makes paths longer and misunderstandings more likely. So we want to replace a process with handoffs and responsibilities with direct, collaborative teamwork. This also means that the responsibility for risk management moves to the team itself.
Many risks can only be recognised by reconciling different perspectives. For example, if there has been a misunderstanding about a key requirement, neither the client nor the team member will be able to recognise this on their own because both are working from false assumptions. Only in dialogue can these issues come to light. Risk management worthy of the name should therefore consciously encourage these dialogues to take place and challenge the comparison of assumptions and perspectives.
In classically planned projects, the achievement of the originally planned goal is usually the best possible outcome. The possible benefit is therefore limited by the level of knowledge that was available at the beginning of the project and decreases as the environment and expectations change during implementation. Any new knowledge that emerges during the project is not foreseen in this approach and is therefore mostly undesirable, even if it could significantly improve the result. We are obviously giving away potential here.
If we break away from this approach, we realise: risks are only one half of the possible events to which we want to be able to react. Opportunities for spontaneous improvement of results are usually not even perceived, let alone used, in our often safety-fixated working environment. So we want to move away from the concept of risk and towards an umbrella term for possible events in the future that are relevant to the project. Let’s call it “contingency” or simply “opportunities and risks”. In any case, we should include possible events with both positive and negative effects in our foresight.
Finally, such a joint consideration only becomes “agile risk management” if this process is interdisciplinary, iterative and incremental and the identified measures take the usual path through the work process, like all other tasks.
A suggestion for a method
With the aforementioned considerations in mind, here is a sketch from me of how it can be done – of course, it doesn’t have to be. At regular intervals, the team holds a collaborative meeting to consider possible events in the future that could have an impact on the team and its project. For the most complete consideration, I would invite at least the Product Owner and Scrum Master (if available), customers and/or project sponsors and of course the development team to this event. Diversity of viewpoints is always a good idea, but when considering potential risks it is essential.
To set up the meeting, we can use a visualisation method that I would call “contingency analysis”6:
In a rather open-ended working phase, a diagram like the one below is filled in by those present. For this purpose, possible events in the future are collected, sorted according to their positive-negative impact and their rough probability of occurrence. We can think of the diagram as an extended risk matrix, expanded to include a range of positive impacts, and without an artificial demarcation into “levels”.
For the identification of measures, one then wants to focus on three areas, namely opportunities of medium probability (how can we make them more likely?) and risks of high to medium probability (how can we make them less likely or cushion them through preparation?).
I see little need for action on events that are unlikely to have a positive or negative impact; improbable events, and positive events that can certainly be expected (a reason to rejoice, but no need for action). Of course, these can also be checked for measures, but I would not place any particular focus on this.
Measures can then roughly fall into one of two strategies, analogous to the axes in the diagram: either to change the impact of the event to the positive through preparation, or to influence the probability of occurrence, i.e. to make risks less likely and opportunities more likely. Identified actions are either implemented immediately (e.g. adjusting the working methodology) or included in the team’s backlog and prioritised and processed like normal tasks. The implementation of the longer-term measures can then be combined on a day-to-day basis with ideas such as the Stop Work Authority card to recognise and discuss short-term risks as well.
When and how often this exchange is useful is certainly context-dependent. It seems to me that it would make sense to hold it a few times a year, or soon after the start of a project, or whenever the parameters have changed significantly (e.g. a new deadline that has to be met). If you don’t want to schedule an additional meeting for this, you can also schedule it instead of one of the regular retrospectives. This format certainly fulfils the mandate of “reflecting on one’s own working methods and adjusting them if necessary”, and it breaks up the often tiring series of “what went well, what went badly, what should we do differently” standard retrospectives.
Of course, the usefulness of these appointments also wants to be inspected regularly and the format adjusted as needed. It will continue to happen that some events can catch the team unprepared – it will also be worth discussing how to recognise such surprises earlier in the future.
A word of warning: deadlines like these have a certain potential for conflict – for example, if directly after the start of a project the customer and the development team suddenly start discussing how realistic the new, brought-forward delivery date still is. I am convinced that it makes sense to have these conversations early, honestly and together, but it pays to be prepared and to have experience in moderation and conversation.
Conclusion
By and large, many agile projects seem to get by without any explicit risk management. I welcome this wherever it is not necessary, and like to remind people of the tenth agile principle of maximising the amount of work that does not need to be done for the sake of simplicity. However, I also experience that there are plenty of situations where a minimum of foresight would have been important. Here, agile teams unnecessarily expose themselves to accusations of unprofessional, chaotic action and damage the very relationships of trust on which agile approaches depend for success.
The solution cannot be to simply stick a classic project organisation with a risk management structure onto an agile team. For two decades now, such “hybrid approaches” have shown that they reliably create more problems than they solve – hardly surprising, since they repeatedly combine methods that were developed for different problem classes7 and whose basic assumptions are not compatible with each other.
In my view, a professionally acting team can be expected not only to look at the past and derive insights from it for the present; but also to use its expertise to recognise future events at an early stage, to observe them and, if necessary, to take preparatory measures. The form in which this is done is, of course, up to the team. However, it is a good idea to use generally accepted ideas and tools from agile contexts – retrospectives, interdisciplinary workshop settings, collaborative visualisation methods and existing processes for collecting, prioritising and completing tasks. The role of “risk manager” certainly rarely has any justification in such an environment; instead, like many functionally-cut specialist roles of the past, risk management simply becomes a day-to-day task of the team responsible for developing the product or service.
Notes:
Other articles in German by Kai-Marian Pukall can be found at Inspect & Adapt and on LinkedIn.
[1] Wohland u. Wiemeyer: „Denkwerkzeuge der Höchstleister“, S. 168
[2] https://ronjeffries.com/xprog/blog/risk-is-the-water-in-which-the-agile-fish-swims/
[3] Cynefin Framework
[4] Blue-red distinction
[5] Scrum Guide
[6] based on a method from “Liftoff” by Diana Larsen and Ainsley Nies
[7] See also the blue-red distinction, e.g. in “Denkwerkzeuge der Höchstleister” or “Komplexithoden” by Niels Pfläging and Silke Herrmann.
Kai-Marian Pukall has published more posts on the t2informatik Blog, including
Modern Agile Principles: Agile work made easy
What parameters does self-organisation need
Decision-making ability – the success factor of teams
Kai-Marian Pukall
Kai-Marian Pukall works as an organisational consultant for Seibert Media GmbH. He has been accompanying agile teams for many years, always with the aim of making collaboration valuable and professional, simple and people-friendly. He prefers to apply the Lean principle “Eliminate Waste” to everything that smells like method and business theatre.