Like many Scrum Masters, Agile Coaches and Agile Managers, I am beginning to understand organizations are complex adaptive systems. Some time ago I decided to dive a bit deeper into Systems Thinking. What I learned might be of value to others, so I combined my findings in a series of five articles, of which this is the last one. (For references to all episodes of the series, refer to the endnote of this article).
Aspects of Systems Thinking
Systems Thinking has evolved a lot since it got started in the fifties. The overview below is a summary of subjects found in publications and lectures of various System Thinkers. This overview was created at the 2019 WPI systems academic seminar: “What is Systems Thinking?”. It’s an insightful overview of the subjects related to understanding complex adaptive systems and solving wicked problems.
Matthew Amissah, Thomas Gannon and Jamie Monat
When I was taught Systems Thinking, I learned it was about “the whole”, drawing causal loop diagrams (CLD’s) to have conversations and to try to get rid of local optimizations. This is very useful, but for some reason I never succeeded in drawing valuable CLD’s outside the classroom. It felt like I did not have enough of brainpower to make CLD’s work. By broadening my knowledge of Systems Thinking I learned about DSRP by the Carberas. These are the tools I was missing to understand complex problems and make valuable CLD’s.
DSRP is an approach that considers thinking itself as a complex adaptive system (CAS), of which systems thinking is an emergent property. (Take some time to digest that one ;-). As described in one of my earlier blogs, each CAS adheres to a basic set of rules from which some behavior can emerge. The basic rule-set underlying Systems Thinking is DSRP: Distinctions, Systems, Relationships and Perspectives.
Distinctions
We make distinctions by determining if a concept is similar to something we already identified. Everything is either an identity or something else. By making distinctions we challenge existing norms, labels and definitions. We also reduce biases caused by the way information is structured.
One of the powerful properties of Scrum is that it makes a very clear distinction in roles, events and artifacts. We also see in the evolution of the Scrum guide how the distinctiveness has improved over time, for instance by dropping the term “team” in favor of “Scrum team” and “Development team”. Another example is how the Scrum guide separates activities from events: Events have a clear time-box, cadence, subject and participants. Hence, Refinement is not an event, because this is an ongoing activity, scheduled as needed with (possibly) changing compositions.
Distinctions are boundaries between “identities” and “the other”. We make distinctions all the time and Systems Thinking wants us to do this more deliberately (within the context of the problem or behavior we are studying).
Image by D. Carbera
Why is making distinctions helpful?
- It improves our problem-solving capabilities.
- It allows us to communicate more clearly and effectively.
- Increases our understanding of those around us.
- It allows us to recognize biases.
- It allows us to see what is missing or redundant.
Systems
Any idea or thing can be split into “parts” or lumped into “a whole”. We look at concepts and we choose if, for our purpose, a concept is a part or a whole. Seeing parts and wholes sets context and system boundaries. Organizing concepts as parts or wholes should be a deliberate choice to help us better understand what we are looking at. Think about the way ordering the words of a sentence or adding punctuation changes its meaning. For example, you know Bob Marley’s song: “No woman no cry”. A general understanding of these words is that without women in your life you will have less pain and grief. However, the punctuation of this line is: “No, woman, no cry.” Reading it with its correct punctuation, we understand that Bob is saying to his wife “Don’t cry, my dear”. (All of a sudden, the rest of the lyrics to this song make a lot more sense too!). Changing the way ideas are organized changes meaning itself.
Image by D. Carbera
Let’s look at a Scrum example. Imagine we observe a poorly functioning team. We observe that there is one person that seems to cause the problem. In that case, we see the person as a whole, the person is the system boundary. To improve the situation, we study the parts that make up that system: Maybe the person has a tooth issue and spreads an awful odor? Or maybe the person had youth-issues that surface now as responsibility avoiding behavior? Now, let’s choose a different system boundary: We assume that the team-member interactions make up the problem. In that case, we consider the team as the whole (system) and the members, their activities and relationships as the parts. A third level to study this problem is to consider the team is being played by forces in the organization, which leads to stress in the team and causes people to pick on this one team member. In order to improve the problematic situation, we look at the team as a part of the organizational system (whole). The different levels of wholes and parts are interrelated, that’s what makes problems “wicked” and difficult to grasp.
In the above example, we see that there is a direct relationship between stress and tension in the team. Let’s assume management is pushing hard on deadlines. If that is the case, will sending one team member to the dentist solve the problem and make the team perform better? Yes, in fact it might, but only for a short while, because this solution will not make the management pressure disappear. Sending the person to the dentist intervenes at a low-level part of the system. This fix is a local optimization that does not improve the system as a whole. I.e. if we choose our parts and wholes incorrectly, we end up applying a change at the “wrong” level and the long-term behavior of the system remains unchanged.
Question: How can we know that our intervention was a local optimization?
Answer: When the problem reoccurs later in time.
Why? A system is a dynamic entity and can flip from a one-state into another when a certain threshold or tipping point is reached. Changing a part in a lower subsystem only affects the set-point (tipping point) of the system state. The behavior of the system as a whole does not change.
Why is seeing systems important?
- It helps us to understand how we (and others) choose to group things.
- It helps us to find flaws in our thinking.
- Awareness of parts of a whole makes us belong and mutually responsible.
- Allows us to see what is missing more easily.
- It structures information and gives it meaning.
Relationships
Relationships are the visible and hidden dynamics of a system. Relationships can be:
- physical and tangible (example: a power cord),
- physical and invisible (example: magnetic force),
- conceptual (example: marriage),
- emotional (example: love, hate).
Relationships between parts of a system create the system dynamics through actions and reactions between things and ideas. Relationships require studying because often they are systems by themselves. We tend to look for simple cause and effect relationships although in reality there are “webs” of causality. Using systems thinking to see webs of causality and grouping them into named relationships with properties can help tremendously. We can look at relationships as being distinctions, which means we define relationships as ideas or things rather than just noting connections between items.
Image by R. Flemm and D. Carbera
Let’s take the example of a Sales team that puts pressure on a Scrum team to deliver. The Sales team has properties (parts) such as team members, sales targets, a sales process, a roadmap and a sales funnel, etc. The Scrum team has team members, a process, product owner, scrum master, a backlog, a roadmap, velocity, department manager, etc. The Sales team and the Scrum team have a relationship that is problematic. The Sales team expressed that the Scrum team is too slow in delivering product. The Scrum team complains about the crazy demands and deadlines by Sales. To better understand the problem we consider the relationship as an element with its own specific properties (parts). Giving this relationship a name helps (distinction). How about hierarchy, supplier or collaboration? Collaboration feels like a candidate worthwhile to investigate. A collaborative relationship has parts like communication moments, channels and frequency, goals, process, timing, etc. Creating a list of parts makes us see that the Sales team has sales numbers as KPI’s. They push customers to buy new tailor-made features so they meet their targets. The Scrum team is responsible for delivering high-quality value (software) every sprint, which becomes more and more difficult with the increasing amount of customization. Getting the teams to define shared goals is a good intervention to change the behavior of the system.
Why are relations important?
- They help us understand the dynamics of a problem.
- They show us how the parts of a system interact.
- Different relationships offer us a different perspective on the problem.
- Seeing the hidden or underlying properties will help us to understand how things work.
- They help us to see (the consequences of) missing relationships.
Perspectives
Plato already knew that we cannot consider anything without taking a perspective: What we focus on is always subject to some perspective. In fact, Distinctions, Systems and Relationships are forms of different perspectives. Being mindful of perspectives learns us that everything we observe is either a point (the thing we focus on) or a view (the thing that is doing the seeing). To be able to understand anything, we need to consider the perspective that is taken.
Image by D. Carbera
The Sales vs Scrum team problem could be considered from various perspectives:
- efficiency perspective
- customer perspective
- team member perspective
- emotional perspective
- salesperson perspective
- product perspective
- competitor perspective
- human resources perspective
- etc…
Purposefully choosing perspectives is all about dismantling biases. Changing perspectives opens new opportunities for finding sensible interventions to a wicked problem. Not being aware of the omnipresence of perspectives can lead to “observer bias” (we see only what we want to see).
There is a famous quote by Wayne Dyer on perspectives:
When we change the way we look at things, the things we look at change.
If you focus only on a rose’s thorns, you will perceive it as a symbol of pain. If you focus on its beauty, you will behold it as a symbol of love. There is also a deeper, systemic meaning to Dyer’s quote. We are in many ways connected to the problem we are studying. Merely by observing a problem, we might influence the problem behavior. This effect is known as the “Hawthorne effect”. For example, If you tell team members you are observing their language, they will think more about what they say than usual, which will skew your observations.
Why is understanding perspectives important?
- Understanding systems is mostly understanding how systems look from various perspectives.
- When we change the way we look at things, the things that we are looking at change.
- Perspectives can expand our thinking by including more options (i.e., divergent thinking).
- Perspectives help to restrict our thinking and cause greater focus (i.e., convergent thinking).
- Gives us nuance and empathy.
End note
Our default way of thinking is bi-valent or black-or-white thinking, regardless of the problem we are confronted with. We can create better solutions for complex problems and eliminate undesired side effects if we adopt multi-valent thinking instead. We become better problem solvers by mixing and matching the four basic elements of Systems Thinking: Distinctions, Systems, Relations and Perspectives.
In five episodes I tried to shed a light on modern Systems Thinking for Scrum Masters, Agile coaches and agile managers: