Agile and Risk Management (3) : Heartbeats and minds

In this third article, I will focus on the question: what’s in it for Agile working teams to be risk aware? Is there an inherent driver ?

Probably everybody working in a risk management environment knows about the methodology that Shell has developed together with the Universities of Leiden, Manchester and Aberdeen called ‘hearts and minds’. The thought behind hearts and minds is that good risk management can only be found if you do not only have a sound risk management system, but also a culture, an environment in which it is ‘normal’ to be and act risk aware. Rules, registration systems and training alone are insufficient.

The level of risk awareness maturity of an organisation can be depicted as follows (this diagram is taken from the article of NVVK about Hearts and Minds (NVVK Info 1812.pdf)).

If you would like a full explanation of this diagram, I kindly refer you to this article. For now it suffices say that the basic thought behind the hearts and minds methodology is physical safety.

Now the good thing about physical safety is that it really appeals to people. They can injure themselves and nobody wants that. They can hurt other people, and nobody in his or her right mind wants that. So if you provide the workers in such an environment with the right information, training and create trust and accountability, they themselves ‘benefit’ directly from acting risk aware themselves. They understand it (mind) and they feel it (heart).

Physical safety is not really an issue in a large part of the financial service industry. When it comes to cash transport it is important, and the same is true for some parts of the facility management organisation, but for the largest part, this type of risk is as rated rather insignificant when it comes to e.g. banks, software development and insurance companies.

In the financial industry, we are therefore potentially missing a central theme of this hearts and minds approach. Of course everybody understands that making a software error can lead to a loss. But when this error leads to for example a successful cyberattack exploiting the software error you made, do you feel or at least have the chance to feel the consequences (like is the case with physical injury) or is it ‘just’ a loss for the company?

Mind you, I am not saying that most people are not of goodwill, on the contrary. Most people take pride in their profession and want to do good. But the question is, will this “want to do good” hold its ground when really pressured by e.g. a senior sales person whose deal is depending on a timely implementation of a software change or a manager who promised something to his or her boss? I believe we all have seen sufficient examples to have at least some serious doubts.

So if one’s own safety is not at stake, how can we reach the heart and not only the mind? How can we create a risk awareness culture in an Agile environment?

Some people are looking for a solution in the “whip-approach”. They would say something like: “if employees did not adhere to the policies and that leads to a loss, and they did not ask for permission, a notation in their personnel file needs to be made”.

In my opinion that is not creating an environment of trust that is needed for a risk aware culture. Instead of learning from mistakes, people will - when this would really be introduced- tend to keep mistakes for themselves, trying to avoid personal (financial) consequences. They fear the consequences. This will most likely drive the risk maturity level of an organisation down instead of up.

But this whip approach does put us in the right direction. Safety builds on the same emotion, namely fear. Fear that you could cause irreversible damage for yourself or your co-workers (or society). But instead of using fear for punishments and authority (that leads to denial), we could use fear for undermining group performance (that leads to sharing).

So what would be the greatest fear in this sense for Agile working teams? Probably you have already guessed it: undermining team (and personal) performance. Delivering late, delivering less, delivering poor quality. So a possible way of making sure that risk awareness is coming closer to the hearts of Agile working teams is calling upon this fear of underperformance. If the teams follow the risk processes, they will minimize the chance that a functionality cannot be put into production because they overlooked a risk. If they use end to end automated testing, even if it costs them time now, they prevent production errors which are way more time consuming to repair later on or as the Chinese put it: prevent loss of face. If they do not use the risk processes, some 2nd line party will probably come and ask for proof that the team is demonstrable in control before anything can be taken into production, causing the team to deliver their results late.

In all honesty, even with this addition, it never becomes as good a foundation for a risk culture based on your own or your co-workers physical safety…... So what extra can we do?

 “Culture builds on processes”, was the statement I made in the previous article. Let’s explore if we can reach our goal: create an inherent driver to work risk aware, by combining the fear for underperformance with the Agile scrum processes.

In Agile scrum a collective challenge process exists: the Retrospective. During this retrospective the team addresses the question how they performed over the last sprint and what can be improved. What could they discuss about risk apart from the obvious ‘did we as a team make any mistakes and what can we learn from them?

In almost all financial institutions a loss registration system is in place. This information can be made useful for Agile teams by selecting relevant incidents, providing more details about the losses and making it available for all teams. Teams can then during the Retrospective ask open questions like:

• can it happen in our team?
• what can we learn from it?
• how can we prevent it?

Why must the teams reflect on lessons learned from the mistakes caused by other teams? Because as stated above, the Agile teams are composed of professionals. I have witnessed many Agile working teams that caused (from a risk perspective) perhaps maximum one or two more serious (potential) incidents per year. So only learning from your own mistakes, does not create a regular heartbeat, there is potentially too little to discuss. But with a large number of teams, the number of incidents to share increases. If you also include the errors that are made by the business or customers because your system does not perform a certain check or errors due to unclarity in the system, enough learnings become available each week.

 For the Financial Industry this means that more openness and sharing of information is required than in general currently is available. If sharing of lessons learned is present in the Financial Industry, it is mostly limited to higher management or within a larger team.

Summarizing: can we really reach the heart of Agile worker in terms of risk awareness to the same extend as is possible in a production environment where your own physical safety is a key driving factor? Probably not. But if we ensure that:

•  risk is part of the Agile Manifesto,
•  sharing information is institutionalised,
• we build on the fact that the Agile teams are professionals,
• we maybe call upon the fear of underperformance but, most importantly ,
•  we ingrain ‘risk awareness’ and ‘lessons learned’ in the Agile process and it is performed with every heartbeat of the Agile rhythm,

 we can in my opinion achieve almost the same level of risk maturity in an Agile working environment. Maybe not hearts and minds, but certainly ‘heartbeats and minds’ is possible.

In the next article, I will have a look at how the 2nd line can facilitate the Agile working teams better. How can the 2nd line, instead of being a nuisance sometimes, a tick the box, become a valuable asset for the Agile teams?

 Please note: This article is written in a personal capacity and does not represent the opinion of the companies I work(ed) with.