Balance High Cohesion with Low Coupling
Author: Jurgen Appelo
A common misunderstanding around systems thinking makes some authors suggest that team members should "see the whole" or "act holistically". For example, we find such a comment in the official literature of the Scaled Agile Framework:
“Leveraging systems thinking allows knowledge workers to see the whole picture.”
This point of view is incorrect in complex situations because it's impossible to see the whole picture of a complex adaptive system. As some complexity thinkers have said, if you can fully understand a complex system, it's not complex; it's merely complicated.
You can see almost any static version of a product as complicated. After all, each product consists of a limited number of parts and relationships. When you study a static picture long enough, you should be able to understand and describe what each of the parts does and how it is related to the other parts. And that's it! You've described a complicated product.
However, everything changes when customers start using the product, when product teams start changing and updating it, when suppliers and partners start feeding it, when managers start managing it, and when platform teams start servicing it. The whole system now includes humans everywhere, making everything complex, not complicated. It is impossible to understand and describe all the interactions and experiences with and around a product when people have entered the picture. Nobody can see the whole anymore.
Complexity science teaches us that no part of a complex system knows what is going on in the entire system. Each piece can have deep knowledge of a small area or a shallow understanding of a wide area, but knowing everything about everything is not an option. In complex adaptive systems, the parts optimize their small areas. Still, because everything depends on everything else, the local optimizations of the parts trigger feedback (directly and indirectly) from all the others across the entire system. And through these feedback loops, the parts correct each other and nudge them in more favorable directions. This is how a whole complex system improves its fitness level.
In the unFIX model, we follow the same principle. Nobody knows what goes on in an entire organization, so let's not pretend that some people have the job of "seeing the whole". Each Crew has full knowledge of their Turf and probably not much else. They optimize for their area, but thanks to Forums, Experience Crews, Facilitation Crews, and other patterns, any local improvements permeate the Crew boundaries and are detected by other Crews in the company. Thanks to feedback cycles, Crews can course-correct each other and, as a result, the entire company improves its performance.
Balance High Cohesion with Low Coupling
In software architecture, a well-known principle says that architectures should have high cohesion and low coupling. It means that individual units should focus and be the best in one well-defined area and leave other responsibilities to others (= high cohesion). At the same time, there should be a few interdependencies among those units: not too many, but also not zero (= low coupling). Through high cohesion and low coupling, the entire system can be made to perform optimally.
Why should it be any different in organization design?
Get every role and every team to focus on their area of responsibility and let them optimize their performance. However, everyone must get continuous feedback from the others around them so that the interdependence between roles and teams results in a fully-connected whole. If you make sure that no role and no team can get away with ignoring the needs of their local environments, you end up with a fully optimized organization.
And nobody sees the whole picture.
