This paper discusses a different way to deal with complexity than suggesting complex systems are unknowable and that we therefore must see what happens and inspect and adapt in response. It acknowledges that complex systems are, by definition, not completely understood. However, by attending to the embedded parts of the system we can understand, we can make reasonably predictable improvements in the system as a whole. It furthermore suggests, that while we have no control over the complexity of what’s outside of us, by improving our own methods, we can pivot when black swan or other unpredictable events occur.
I want to be clear that this discussion is in the context of creating and offering services to customers of an organization, a complex endeavor. I am not talking about complexity as it relates to nuclear reactors. When attempting to improve a way of working, it is often a good idea to understand if the work being done is complex, complicated, or even simple. With knowledge work, it’s almost always a good idea to assume you’re dealing with complexity. But in reality, you can’t separate an organization into its component parts. This is an essential concept of systems thinking that everything relates to everything else within a system – even the system containing it. For example, thinking the act of an employee putting shoes into a box prior to shipping is simple ignores the fact that they might be mad at their employer at the moment and intentionally put the shoes in the wrong box.
The key difference in attitude is not in recognizing we have different states, but in what you do after you see you have complexity present in your workflows. The important question “do you believe you can be proactive in your actions and reduce waste by taking advantage of what you know from theories presented by Flow, Lean, and the Theory of Constraints and using feedback to manage what you don’t?” The first step in doing this is to identify and use foundational principles.
A foundational principle is a principle that stands on its own and applies virtually everywhere. For example, delays in the workflow will create waste. And having people work beyond their capacity will cause multitasking and delays in workflows. These can be used to create guidance, e.g., “keep workloads below capacity.” Some people call these “first or foundational principles.” We prefer the term “foundational” to remind us that they represent the foundation for guidance. Also, to remind us that we need to always be validating them and not take them for truth.
Systems thinking tells us to attend to the relationships between the components of a system. Some of these are clear. Some merely involve a few others so as to be understandable. But some are so interrelated as to not be understandable – hence complex.
People take two attitudes about this complexity. Some believe this makes using the causality we understand less useful. While others believe that we can still take proactive action with it. In “The Choice”, Eli Goldratt says “The first and most profound obstacle is that people believe that reality is complex, and therefore they are looking for sophisticated explanations for complicated solutions. Do you understand how devastating this is?” He continues with ”The biggest obstacle is that people grasp reality as complex when actually is surprisingly simple.”
He is not referring to an understanding of what’s happening. After all, he was a physicist and certainly was aware of the complexity of nature. He’s referring to what it takes to control and learn about systems. In particular, while product development is complex you can drive it by attending to relationships you can understand and be prepared for things to happen from what you don’t see/understand. And when these occur, you learn more about the system and how to work within it.
This does not mean everything is predictable. Far from it. Non-linear events (an event where a small mistake causes a big result) cause a tremendous amount of problems. But we can manage those with quick feedback, which creates visibility on what is happening and unobscures the fog complexity causes. In the physical world, this is not possible. Three Mile Island was caused in large part by a lack of visibility of what was happening. That need not be the case in knowledge work.
The bottom line is we shift our focus from understanding the state of our system to seeing what actions we can take that increase its effectiveness. With this attitude, you also look to see what are the issues that matter. Instead of identifying that we’re in chaos, we look to see how we can avoid the chaotic (non-linear) events that are driving us to it. In knowledge work, I have identified nine factors that provide guidance in making good decisions on how to improve your work. I call these the factors for effective value streams. This shift also has us look at how to make a cohesive set of practices around the value stream networks present. All of this enables organizations to be able to pivot quickly, so when events outside of the organization occur, they can respond quickly and efficiently.
What happens when you don’t take this attitude is made clear by observing Agile’s most popular frameworks – Scrum and SAFe. Scrum is based on its creators’ own values and principles, not foundational principles which are objective. You must follow them, or you won’t be doing Scrum. But they often don’t provide guidance on how to achieve them and aren’t appropriate in all situations. SAFe is a collection of practices that don’t fit cohesively because foundational principles are missing as well. Ironically, Scrum’s simplistic and SAFe’s overly complicated approaches stem from the same belief – the world is too complex to understand, so use the practices they give you to get where you want to be.
Recognizing this creates an opportunity to use foundational principles to improve both Scrum and SAFe. It’s not that either of these frameworks doesn’t provide value, it’s that they each have gaps that enable filling in the blanks in Scrum case and mostly simplifying SAFe in its case.
Associated Workshops
If you want to learn more about this approach, check out these two online, Amplio workshops:
In this every other week series Al Shalloway will discuss topics he thinks are important but either overlooked or done poorly. These will include topics like dealing with complexity, the risks of using frameworks, and how the lessons of engineering can be useful in product development. He will also talk about his own approaches to the team, enterprise, SAFe, and being a coach.
Amplio Lean-Agile Teams Masterclass
This workshop is primarily for coaches who want to go to the next level and transcend particular approaches but instead think for themselves. It is also useful for people in an organization who are responsible for how effective their coaches are.