How a systemic approach can make change management easier: 3 real-life case studies
By Laetitia Thernier, Agile coach @ leboncoin and Rémi Beslot, Systemic agile master @ SNCF Connect & Tech
As a scrum master, manager, agile coach, or simply someone who wants to improve things in a company, have you ever been in a position where you try something new with the team, and it works for a little while and then it stops and you’re back to square one? Or perhaps your multiple attempts to change a situation haven’t worked as expected, so you feel stuck? Or you just don’t know where to intervene and who to involve in the process?
The problem here is that you are following the client’s orders when your real boss is the system. It’s one of the core concepts of the systemic approach, a way of thinking that could help you perceive and handle change management differently.
Would you like to know more? As experienced agile experts, the two of us were trained for two years, starting in 2021, on how to use the systemic approach. Having it in place has helped us with complex situations in our day-to-day work, so we wanted to share it with you. This article will outline 3 case studies that illustrate how a systemic approach can help with change management.
The systemic approach
The core principles
System
A system is an ensemble of elements (sometimes grouped into subsystems) that interact in a way to achieve a specific goal, similar to the organs in the human body that keep you alive, or a team of people responsible for creating a software application.
Relations
The concept of relations refers to the recurring interactions occurring between the elements that lead to a mutual influence.
Rather than studying the elements themselves, the systemic approach focuses on the system and its relationships.
The poppy metaphor
An effective way to illustrate how the systemic approach differs from conventional thinking is to use the poppy metaphor described in The Systemic Approach: To Manage Uncertainty and Complexity (in French) by Arlette Yatchinovsky.
A cartesian approach to studying the poppy would involve gathering, dissecting, and classifying it. This means that it will only be viewed from a botanical point of view. In contrast, the systemic approach does not involve killing the poppy, but observing it in its context at different distances and timings, and observing its interaction with its ecosystem (other plants, insects, the sun, etc.). So it is more of a multidisciplinary approach.
Case study n°1: Using the systemic approach to identify the right system for intervention (by Rémi Beslot)
Context
As a scrum master (SM), I worked with a new team consisting of 10 developers and a product owner (PO). Except for the PO, everyone was familiar with agile culture.
Almost immediately, I received complaints from some of the developers about the PO, claiming that he micromanaged them and questioned their decisions.
System version 1: SM & PO
In order to resolve the issue, my first intervention only involved me and the PO. My belief at the time was that the PO’s behavior was the problem. Therefore I asked him to give more autonomy to the developers by introducing him to the agile methodology and helping him to apply it. Additionally, he attended external training sessions on the agile approach. Although it helped to improve the situation, developers continued to complain and there was no progress made anymore. This ended in tension between us, with him insisting that not all the developers had complained.
At this point, I realized my system was too restrictive. We needed to include everyone affected by this issue in order to move forward. It was time to expand the system.
System version 2: SM & PO & developers
Now we were going to examine who among the developers was affected by the lack of autonomy and how the PO and the developers interacted regarding it. My observations were then discussed in retro meetings. It confirmed more autonomy was needed.
But what I learnt most importantly was that there were a lot of tacit beliefs and unsaid things about each other’s responsibilities. When answering a request, developers used tacit rules based on their previous experience or the requester’s preferences. That led to a lot of tensions between them, which had a negative impact on their relations.
The responsibilities of each element in the system needed to be clarified. So we worked together to define a canvas of responsibilities. And the results were quite good! As much as 70% of the autonomy issues were resolved this way.
But what about the remaining 30% where we fell back to command and control. I felt after a while that I had done everything I could to help this system, but some mysterious forces were working against me. To get a strong 100%, I might need to look at what was happening outside this system.
System version 3: SM & PO & developers & other teams & SM manager & PO manager
The goal with this was twofold: To find out if this autonomy problem existed in other teams working on this big asset and to include the heads of the asset in the resolution.
First, I confirmed other teams had the same autonomy versus control problem.
Then, to find out why it was happening, the SM’s manager and I used the perspective of the job descriptions. Conflicts between some of the SM and PO objectives were identified, which was particularly problematic for people who should be working together every day.
I began to think that maybe the common vision of the SM and PO roles was not explicit enough, and that we were not fully aligned about what we were trying to achieve in the system.
It led to workshops about the system’s purpose and how we contributed.
Key learnings
- Issues evolve as the system evolves.
- In order to find the most efficient system for change management, it is important to consult all stakeholders involved in the issue (including us) that we are trying to resolve. But be realistic: The whole company can’t be involved!
- You will find a solution by exploring the problem, not the other way around.
- In a system without a shared goal, delineation of responsibility in the working environment becomes blurred and tensions arise
- A cartography tool of systems and relations can help to visualize the right system and its interactions and issues, as well as its purpose.
Case study n°2: Using the regulation mechanisms to help a system to change (by Rémi Beslot)
Regulation mechanisms allow a system to stabilize after perturbations in order to protect it. A good illustration would be the human body, which maintains a constant temperature to remain viable. Likewise, organizations may regulate themselves by preventing changes to maintain individual and collective interests (safety, control, power, identity, etc.).
In Managing Using a Systemic Approach (in French), Dominique Bériot identifies 3 types of changes:
The rupture change
The system is put in a new environment with new interactions and has no choice but to adapt. Examples would be a layoff plan or an unplanned implementation of a new information system.
This approach is often brutal and can lead to people suffering.
The evolutive change
The system is modified in a progressive way, either partially or completely. This is often the case when a team has adopted continuous improvement as part of its agile process.
The homeostatic change
The system has a target, but its regulation mechanisms are so strong that it fails. It is very common in organizations with little or no involvement from the board, or in teams where habits are deeply embedded.
Context
The team I was a SM on included a PO, developers, and proxy POs who worked on conception upstream out of sprints. The developers worked in an agile environment with scrum-like processes and everyone seemed to get along well.
However the proxy POs soon started expressing frustration, claiming that they were overwhelmed with work that they needed to set deadlines for. Additionally, the PO complained that he was experiencing too much tunnel effect and had difficulty planning due to the lack of overview of conception.
Fixing the conception phase?
My first conclusion after exploring the problem was that it resided in the conception phase. The conception lacked transparency and focus, as well as autonomy and trust.
But I quickly realized that I had a bigger issue: The way of working had remained the same for years, despite attempts to estimate using T-shirt sizing and adding more reports. There was a strong belief that it was impossible to proceed any other way. I was in an ultra-stable system, and I was afraid whatever change we would put in motion, it would flop, like a homeostatic change. Taking a different approach was necessary.
Experimenting with a micro rupture
To the proxy POs, I suggested they try the developers’ processes: Short iterations, splitting tasks, focus, common objectives, transparency….
For these individuals, this experiment was a micro rupture due to a sudden change in their environment (interactions and communication). Nevertheless, the possibility of going back softened the blow. Having a clear idea of what was expected of them (working like developers) also helped them feel more secure. Regular feedback sessions were organized to track progress.
Dealing with the regulation mechanisms
One of my roles as a SM was to respond to people’s reactions and help them overcome the problematic ones. Some of the proxy POs were afraid of this way of working because they felt they would be spied on. Other people in the team didn’t see how it would benefit their roles. Some of them were also happy about the experiment and wanted to help.
I had to listen to all of those reactions, deal with the fears, paradoxes, and beliefs that arose, clarify the vision behind the experiment, and answer each team member’s concerns. But I also didn’t need to rush: I had some enthusiastic teammates and a history of trust in the team to rely on.
After several months of trialing this, it turned out to be an effective method of working for the proxy POs in the long run.
Key learnings
- Understanding the dynamics that maintains a system in a stable state (preventing it to evolve) is essential
- Changing these dynamics requires listening, clarifying, and answering each participant’s concerns.
- Do not be afraid to rely on motivated people to drive change, since they can amplify your efforts.
- Keep in mind that changing a homeostatic system can require an internal or external stimulus (in my case, an experiment).
Case study n°3: Using the systemic approach after unsuccessful attempts to solve a problem (by Laetitia Thernier)
A failed attempt is a solution that was used to try to solve an issue but did not work. As Peter Senge, the author of The Fifth Discipline: The Art & Practice of the Learning Organization, puts it, “Today’s problems come from yesterday’s solutions.”
Context
A product manager (PM) was building a software solution for internal users. She asked me to train them and their manager on agile methodologies because they didn’t understand the way she worked.
Even though she was presenting a solution, I suspected there was a relationship issue involved.
Therefore I investigated the complaint to find out what the real issue was. My discussion with the PM revealed that she was unable to perform her job properly due to the behavior of one internal users’ manager: She was spending too much time and energy dealing with his issues when she had more important things to do. Clearly, training wasn’t the best solution.
As this had been going on for quite some time, I decided to investigate the failed attempts by this PM to resolve it.
Examining past failed attempts
Solution 1: Be as reactive as possible
The PM tried to fix the product whenever the internal users’ manager complained to her. But despite the proposed solutions, he was never satisfied.
Solution 2: Get managers involved
She then decided to involve her manager and the internal users’ manager to avoid dealing with him directly. To begin with, it worked, but the managers quickly became frustrated with the internal users’ manager’s complaints, making the situation worse.
Identifying a common theme
It struck me that there was a common theme in all those failed attempts to repair this relationship between the PM and the internal users’ manager: They interacted like customers and suppliers.
My goal was then to figure out why this type of relationship existed. As it turned out, this PM had worked as a consultant for years and felt obliged to fix any issues internal users encountered. In her opinion, it was her responsibility alone to come up with constructive solutions.
But she adjusted her outlook after some reframing discussions were held: Building solutions with other people was something she was now open to. The next time the internal users’ manager complained, she asked him what solution he would suggest instead of directly proposing one. The first time she did that the internal users’ manager didn’t respond, which left her thinking that maybe the issue wasn’t that urgent or that he had found a workaround.
As the relationship between the internal users’ manager and the PM evolved, it became more like a partnership, resolving the initial problem.
Key learnings
The approach used in this case study was inspired by the book How to Work with Just About Anyone: A 3-Step Solution for Getting Difficult People to Change by Lucy Gill.
To resolve a problem based on previous failed attempts, the below steps should be followed:
- Identify the problem without judgment.
- List any previous failed attempts to resolve the problem in order to identify a common theme.
- Implement something new by softening beliefs (sometimes just stopping proposing solutions is enough).
Taking a deeper look at the systemic approach
The 3 real-life case studies detailed in this article were presented to give you an overview of how the systemic approach can help you handle change management.
Besides being effective in dealing with issues, the systemic approach also allows coaches like us to expend less energy since the problem-solving then requires less effort. By taking a step back and being able to think things through, we experience less frustration and fatigue.
Keep in mind that we only introduced a few concepts of the systemic approach, which actually covers much more. We didn’t mention, for instance, systemic reflection, the feedback loop, or patterns. The systemic approach can also be applied to other areas, not just companies.
If you have found this article helpful, we hope you will be interested in diving further into the systemic approach!
