Shifting the Burden – Using Systems Thinking to build high-performing teams

/in , , /door

Systems Thinking provides us with useful insights how organizational systems work. The insights are often surprising in the way they help explain common dysfunctions in organizations. It is a pitty that beyond the field of organizational scientists it doesn’t seem to be very well known. Systems Thinking is part of the foundation of Agile: Agile scaling frameworks like LeSS and SAFe both explicitly mention Systems Thinking in their underlying principles. Yet, rarely do I come across agile coaches that even have a mediocre understanding of ST. Most have even never heard of it. If you really want to understand the barriers of agile in organizations, both Systems Thinking and Complexity Theory, also not that well-known, are crucial. Because even agile coaches or should I say especially agile coaches, fall into the traps of local optima and symptomatic solutions. So let’s explore how Systems Thinking can help in building high-performing teams.

If you have a headache and you take an aspirin and the headache goes away, then you might just be happy with that and not worry about why you had a headache in the first place. Next time you get a headache, you just take another aspirin, because it worked the first time. Pretty soon you will get used to it and always keep aspirin around and never look for a more fundamental solution to headaches. Taking aspirin will make it less and less likely that you actually adjust your health so that your body works right in the first place.

Systems Thinkers discovered patterns of cause-effect relationships in organizations that are called archetypes. Shifting the Burden is one such archetype, and the headache story above is an example of it. Here’s how it works: We have a problem symptom. There is a fundamental solution to the problem, although it usually works at a delay. The fundamental solution gets overlooked very often because of short-term thinking, pressure within the organization to come up with a quick fix, and a poor understanding of the relationship between cause and effect. Instead we ‘shift the burden’ to other solutions, easy fixes that seem to work well. Unfortunately we only deal with the symptom and not the underlying problem. Covered up by the symptomatic solution, the underlying problem grows worse unnoticed. We use more and more of the quick fix solution because that seemed to work, further reducing the pressure to seek a fundamental solution. Eventually the organization’s ability to solve the underlying problem gets undermined.

Another common example in the agile world is a manager that is trying to empower teams by delegation. But as the team struggles he steps in to help them, with all good intentions. Over time this reduces the ability of the team to solve issues themselves. Instead they increasingly get more dependent on the manager. The overprotective scrum master is another well-known phenomenon in this category. Although often praised for the good relationship he or she has with the team and the great atmosphere in the team, the scrum master unintentionally effectively has become the leader of the team, with everyone depending on him or her.


The picture above is a causal loop diagram that explains the generic Shifting the Burden archetype. The diagram depicts the quick fix solution that temporally lowers the problem symptom, and the fundamental solution that would lower the symptom as well, although usually at a delay. There’s a side effect loop that shows we get more dependent on the quick fixes as we use them undermining our ability to address the actual underlying problem.

Now let’s get back to our team. I have seen many teams like this where the team itself insists they are a strong team: they tell each other lots of stories about their private life, they have drinks together and organize the occasional team event. But if you observe the team a little closer you will notice most conversations are quite shallow, everybody’s playing nice to each other. The teams reaction to conflict is to cover it up. As a result the team does not learn how to deal with conflict. The more they revert to the symptomatic solution of smoothing things over, the less the team will be capable of working on a fundamental solution, which could be working on team cohesiveness by creating trust, coaching the team in conflict resolution and a shared sense of accountability for results. This is described in the first part of the diagram: causal loops B12 and B13.

In a complex system however all parts of the system are interconnected and a change in one part can inadvertently lead to a problem elsewhere. We often find series of interconnected shifting-the-burden structures where one fundamental solution is another problem’s symptomatic solution.

So how does the fundamental solutions become the symptomatic solution of another problem? While team cohesiveness grows a team identity starts getting developed.  They slowly develop a ‘them-against-us’ mentality towards other teams or the surrounding organization. People outside of the team start perceiving the team as inward-thinking, taking care of only themselves, even if not in the interest of the larger organization. Conflict with the rest of the organization starts to grow.

The fundamental solution of building team coherence to the conflicts-within-the-team-problem has now become a symptomatic solution of a new problem: conflict between the team and it’s environment (causal loop B15). The team tries to deal with the new conflict by closing their ranks, sticking together, which in the ends only decreases their ability to fundamentally deal with the rest of the organisation in a constructive manner.

So now we need to look at a fundamental solution to his problem, like helping the team to build a better understanding of the part they play in the larger organization (causal loop B16). You could encourage the team to explicitly define some of their team goals as contributions to higher organisational goals. This is actually a very powerful way to deal with the issues we inherit from today’s silo organisations: give teams or departments a goal they cannot achieve by themselves, but only by collaborating with others.

This practice is in contrast with the popular agile practice of giving teams their own domain to focus on. We are strongly apposed to this. The logic behind it is to encourage teams to take ownership of their own area. But teams don’t work in isolation. They are part of a bigger whole, and this practice will unavoidably lead to local optimization and inward-focusing teams. Systems Thinking can help you understand and predict that.

Note that we covered only one Systems Thinking archetype in this article and only a fraction of the concepts behind Systems Thinking. Nevertheless there are valuable lessons for agile coaches or anybody working on high performing teams:

  • Always focus on the fundamental solution vs a symptomatic solution. Withstand organizational pressure for quick solutions. There are no quick fixes to complex problems.
  • Note that a fundamental solution often needs to be discovered. In many cases it is not a matter of analyzing, but of discovery through experiments.
  • Be aware that the more one applies a symptomatic solution the less one becomes able to come up with a fundamental solution.
  • Realize that a fundamental solution can at the same time be a symptomatic solution for another problem.

Do you want to know more on what Systems Thinking can do for your team and organization? Attend one of our Management 3.0 workshops.

Notes:
[Martin Knapovsky. Shifting the burden archetype. https://www.knapovsky.com/shifting-the-burden-archetype/]
[Daniel Kim. Shifting the burden revisited: Turtles all the way down. https://thesystemsthinker.com/shifting-the-burden-revisited-turtles-all-the-way-down/]
When your only tool is a hammer

If your only tool is a hammer…

/in , , , , /door

The environment of organizations changes at an increasingly fast pace. Complexity and uncertainty are on the rise. But the set of tools that management uses to manage and design their organizations, is changing very slowly. There is an increasing mismatch between the applicability of tools used and the problem domains of modern organizations. How can we assess which domain we’re in and if we are using the appropriate tools?

There’s no denial that organizations operate in a world of fast change, uncertainty, and constant flux. Windows of opportunity open and close faster and faster. Maintaining a sustainable competitive advantage is pretty hard these days. It also seems apparent that most organizations are ill equipped for dealing with rapid change. One indicator is the life expectancy of organizations. It seems to be shrinking at an alarming rate. Professor Richard Foster of Yale University led a Innosight study that shows that a 61-year tenure for the average firm in the S&P 500 index in 1958 narrowed to 25 years in 1980, to only 18 years now. Even more, at this rate by 2027, over 75% of the S&P 500 will be companies you have never heard of. That’s pretty alarming, isn’t it?

There’s obviously work to do for the management of any organization. Complacency is your biggest enemy in this world, it is a one-way street to irrelevance. The business graveyard is full of companies that either reacted too slow or not at all to change. We don’t pretend to have a silver bullet that transforms any organization into a resilient adaptive organization that can deal with anything. But a first step is to be able to asses which problem domain were in and if the tools we use match the domain. Unfortunately, many organizations stick to tools they know like hierarchy, centralization, focus on efficiency, strict rules and processes, linear planning, etc. There’s nothing wrong with these tools per se, it is just that they were designed for organizations that existed about 100 years ago. Many management tools are, more or less, still the legacy of Frederick Taylor’s Scientific Management and Henri Fayol’s functions and principles of management. The world has changed dramatically since then. In the Western economies there aren’t that many industries anymore where these tools work well.

Every organization, department, team, or process is situated in a specific problem domain, each with its own appropriate tools. So how can we tell which one we’re in. A very useful tool here is a sense-making framework called Cynefin. The Cynefin framework has four main domains, and a fifth one called disorder, that each describe the context in terms of the relationship between cause and effect. The four main domains are called obvious (I still prefer the old term ‘simple’), complicated, complex, and chaotic. The disorder domain is used in case it is not clear in which domain we are.

For a detailed description of the Cynefin framework, you can read the excellent Harvard Business Review article by the framework’s founder Dave Snowden. For the purpose of this article we keep the explanation short: In the Obvious domain, we can easily categorize the problem we face and pick the appropriate checklist or process description to solve it. Because the environment here is pretty stable and predictable we can focus on optimizing best practice processes. A simple loan approval process is a good example.

In the Complicated domain things are not as simple and predictable. We need experts to analyze the situation before we can respond. Most of the time there is still a noticeable relationship between cause and effect but it can be separated in space and time making it hard to spot. This is reinforced by management structures like silo’s and KPI’s. We make a decision in one silo, let’s say sales, which has an undesirable effect on another silo, let’s say operations. We don’t see the relationship between cause and effect here because it occurs somewhere else (place) and maybe with a delay (time). Our focus on sales, reinforced by a KPI that just measures sales output, causes us to miss the unintended consequences for the operations department.

The Obvious and Complicated domains together are called the ordered domains. Many organizations think they are in the ordered domains, whereas an increasing number or situations in organizations, teams and processes actually fall in the complex domain, which requires a completely different approach. Because in the Complex domain, good or best practices won’t work. The environment is not stable or predictable, we therefore cannot simply repeat what worked in the past. Nor can we plan the future. We can only discover it by experimenting. The relationship between cause and effect might be there but in most cases can only be seen in retrospect. This is counterintuitive for many managers and therefore hard to accept. There is a dominant tendency to wanting to be able to control and predict the future, even in situations where we can’t, and even if we experience time after time that our carefully crafted plans quickly fall apart.

Now take an invoicing process for example. Most organizations sell something, so invoicing is a common process. You might think invoicing is a predictable stable static process that can easily be handled and optimized by an automated process, and therefore falls into the obvious domain. You are right. The danger is that this makes management rely on processes and rules only. It is not the 95% of correct invoices that matter, but the 5% that are incorrect or exceptional. These are the ones that take up most of the time, and are a danger to the organization’s reputation if not handled well. You cannot handle the exceptional cases the same way as you do predictable ones. But most organizations do. If an exception is found, we create another rule for it. If a customer complains about a wrong invoice we adapt the process. Until the next exception. And the next one. Our system slowly becomes hard to understand and maintain, slow to adapt to new situations, and very costly. And we still find ourselves constantly surprised by new exceptions we haven’t covered yet. What makes matters worse, the way we handle customer complaints on wrong invoices suffers from the same problem: Customers Service reps tend to use strict scripts that handle standard situations well. But the frustration of customers comes from the non-standard mistakes in the first place, and the inability of customer service the solve the issue only adds to the frustration.

Sounds familiar? It is a constant source of airtime for television consumer shows: telco’s, energy companies, and insurance companies getting scrutinized for their inability to properly deal with non-standard situations that appear so obvious for the customer and viewer. It is a classic example of using the wrong tool for the wrong domain. Yet these companies never seem to learn. What’s the standard reply of every spokesperson or executive brave enough to appear before the camera, when asked how they are going to prevent these issues in the future? “We will analyze the process and improve it”. Sigh…

And that brings us to the key takeaway of this article: if you don’t know which domain your situation is in, your will probably treat it as the domain of your preference and the one you are used to. And in many cases that turn out to be the wrong one. You will then be using tools that are not wrong per se, but they are inappropriate for the problem at hand. After all, if your only tool is a hammer, then every problem looks like a nail…

 

Comments on SAFe 4.5: is it all cosmetic?

/in , , /door

Recently SAFe 4.5 was released. Of course there is a lot of information from SAI itself on what’s new in SAFe 4.5, so I want won’t cover all changes in detail here but focus on adding some comments on the significance and usefulness of the changes, or lack of it for that matter.

Cosmetic surgery isn’t always a bad thing

Let me start with something that might feel cosmetic but actually is the most significant improvement in my opinion, namely the fact that the ‘Big Picture’ didn’t get bigger or more complicated this time. From SAFe 3.0 to 4.0 the framework went from three layers to four. In my SAFe courses I sometimes joke that hopefully SAFe 5.0 will not have five layers. I still spend quite some time explaining you should not consider using the Values Stream layer unless it is a very large complex SAFe adoption. While the challenge of coordinating multiple trains in a single Value Stream is of course real, the solution SAFe presents in the Value Stream layer leans rather high towards processes if we consider the Agile Manifesto value Individuals and Interactions over Processes and Tools. In this respect I rather like the most basic coordination mechanism in LeSS: Just Talk. We can come a long way using this mechanism before we actually need to define formal processes in my opinion. It is actually a trap for larger bureaucratic organizations trying to transform to a more agile organization: they have the tendency to model everything in processes instead of telling people to just talk to each other whenever there is something to coordinate.

So the Big Picture didn’t get any bigger this time. Actually it got a lot cleaner. The most significant change in this regard is the configurability of the Big Picture. SAFe now has four base configurations targeted at a specific context. Each configuration only displays the constructs that are relevant for that configuration, making the big picture a lot easier to read. The four configurations are: Essential SAFe, Portfolio SAFe, Large SAFe, and Full SAFe. Selecting a configuration and watching the Big Picture change accordingly is actually quite fun and insightful.
Second, the Big Picture got a visual make-over making it less cluttered and easier to read. SAI claims they actually added more stuff then they removed so kudos to the visual designer.
Third, the Value Stream layer is renamed to Large Solution. Again, this seems purely cosmetic, but as I said I spend a lot of time explaining to people you don’t need to do everything on the Big Picture just because it is on there. Calling it Large Solution will definitely make it easier to understand you only need a large solution when you have a… large problem.

Now you might wonder why I spend so much time on cosmetic changes. The reason is the ‘completeness’ of the Big Picture is both a blessing, you click on anything and instantly get tons of information on the topic, and a curse. Organizations have a tendency to want to implement everything on the Big Picture because they think they are supposed to. The overview can also be quite overwhelming at first glance. And it also makes SAFe an easy target for a sometimes rather loud group of agilists, sitting comfortably high on Mount Stupid, shouting down that SAFE is not agile at all, usually while having no more experience than glancing at the Big Picture at scaledagileframework.com. Yeah, I could just ignore those people but unfortunately they tell their tales to customers as well. If you haven’t heard of Mount Stupid, also known as the Dunning-Kruger effect, it is the phenomenon that people who are the most ignorant on a subject are also the ones most eager to share their opinion on it. Sounds familiar?

Lean Startup

Of course there are more substantial changes too. But you can read about those in detail on the SAFe website.

One is the integration of Lean Startup. A very welcome addition, no doubt, but to be fair there was nothing in SAFe 4.0 that prevented you from using Lean Startup within SAFe. I have actually promoted the fact that everything is a hypothesis that needs to be validated as fast as possible from the start. I have also seen companies use Alexander Osterwalder’s Business Model canvases and Value Proposition design; or Ash Maurya’s Lean Canvas successfully within SAFe. We don’t need it on the Big Picture for this. But the guidance is of course welcome.

Other changes

The role of DevOps is growing in SAFe 4.5 which is a good thing. Not much I can add to that. Continuous Delivery is emphasized more and has gotten a bit more substance. Good, but you were supposed to take Continuous Delivery very seriously anyway already.

Now we all know that delivery and releasing are not the same but they are related of course. One noticeable change on releasing: it has gone from Release on Demand (v3.0) to Release Anytime (v4.0) and back to Release on Demand again in v4.5. Make up your minds guys. 😉

What else? The Implementation Roadmap is there, but to be honest it was already published before the release of 4.5. The implementation roadmap is a big step forward from the rather ridiculous 123 model that seems to have dropped of the Big Picture. Thankfully. Tons of useful information there but one major flaw still remains: It is still a more or less linear process. I strongly feel that a change process should also be iterative, based on experiments and short feedback loops. I recommend looking at Lean Change Management and combine it with the Implementation Roadmap.

Conclusion

So although there are lots of useful additions and changes to SAFe 4.5 the most significant changes are the ones that might appear purely cosmetic at first glance. I think those can actually prevent some organizations from falling into common traps.