Changing organizations is hard. We are entrapped in what is called a Complex Adaptive System (CAS). A complex adaptive system is a system in which a perfect understanding of the individual parts does not automatically convey a perfect understanding of the system’s behavior. A common way to deal with complexity is to try to understand it better. To wade into the complexity without understanding it.
While we do have to accept complexity and that true change emerges, there is another opportunity than just accepting we’re in a complex situation. This is to learn how to look at our system in a way that lets us see what the issues are. The first step in looking to improve our methods is to understand our problems. We can then come up with a roadmap for fixing them. While fixing an organization wide problem may be complex, knowing what to look at to decide what needs fixing is not. This enables providing clear reasons for change which is critical since if people don’t understand the purpose of the change being asked of them they will often resist it.
When one looks at a Rube Goldberg we may think “wow, that’s really complex.” But, it’s actually what we like to call “complicated.” What’s the difference? While you may feel overwhelmed in complicated situations, if you investigate them deeply enough, you can see how all of the pieces work together. Cars, for example, are examples of something that is complicated. This means that we can reasonably predict how they are going to act. As anyone who has had a car breakdown, however, there are still what are called “non-linear events.” That is, a small change that has a big impact. This means that even in complicated situations we need to be aware of unexpected things may happen.
In a complex situation, however, no amount of discerning how things interact with each other will make it understandable. The interactions present tend to take on a life of their own and defy true understanding. The challenge then, is how do we get an understanding of what will improve our methods? Product/service development/maintenance is very complex. Deciding how to change how we work is not simple for a variety of reasons. Some changes prove to be more significant than others and some should be done before others since they will both provide a greater return and set the change for other changes.
Our intent is primarily to make effective change in the system’s behavior. Understanding how to do this is our primary concern. We are not trying to predict what will happen when we make a change as much as we want to see what action we take will have the greatest positive impact on both our approach and our learning. This learning may result from our actions not having the result we were looking for.
To accomplish this requires looking at our world in a way that it appears to be simple. This results in being able to make better decisions. To be clear, we’re not attempting to come up with simple solutions to complex problems. We’re attempting to see a complex world in a simpler manner.
This is not trying to identify those actions that, when tied together, could create a framework. That’s still an attempt at solving a complex problem with a set of well-defined solutions. Nor is it an attempt at discovering how the world works. That would still have to combine these insights. What we want is to change our perspective so that how we see the problem literally becomes simpler.
This article expounds on the following concepts:
- Understanding why it’s hard to make predictions about change
- Although we may not know what specific solutions are present, we can determine what challenges we must solve
- No matter how well we think we understand our system, we must recognize there is no guarantee we understand how it will behave.
There are many interrelated reasons that make our predictions about what effect a change will have on our system less accurate than we’d like. These include:
- there are relationships between issues that we either don’t see or aren’t attending to (e.g., making batch size smaller may increase transaction costs)
- not understanding these relationships (i.e., we see the relationship but misinterpret it)
- there is always potential for a chaotic event – that is, an event where a small thing (e.g., misunderstanding) makes a big difference. A great example of this is the different teams of the Mars Polar Lander using different units of measure people will exhibit unpredictable behavior at times for no rational reason
- a degree of unpredictability that is just inherent in complex systems
The Theory of Constraints puts forward the concept of inherent simplicity – the presumption that inherent in complex systems are rules that, when understood, enormously simplify how to look at the system. These rules already exist. We must find them and take advantage of them. Doing so enables us to increase performance and reduce or eliminate the challenges we are facing.
When we apply inherent simplicity through the eyes of Flow and Lean we see our workplace in a different light. Instead of looking for the complexity in the problem domain, let’s look at it from the perspective of Flow and Lean. We are not trying to look at our world through the principles of FLow and Lean. That would still be too much to do. What we want are a few dimensions that, when we explore them, expose most, if not all, of the significant issues commonly present. We have found the following to do this:
- how workload relates to capacity
- efficiency of the value streams
- batch size
- level of collaboration
- what management’s role is
- how planning is being done
- quality of the product
(Note I am currently writing up more detail on these factors. Please take the link, when available, to learn more).
It is important to understand the true nature of the system we are in and how we can see to change its behavior. We run the risk of waste or ineffectiveness if we don’t understand what we are actually dealing with. The following table lists several dimensions of inherent simplicity and what actions can be guided by them.
While we can start with these examples, it is important to not fall into the trap of using these as mantras to follow and not continuing the exploration of the inherent simplicity in your system.
While giving acknowledgement to Theory of Constrains for the term “inherent simplicity”, we prefer to call what we’re trying to do a bias for simplicity. Instead of looking at our problem as intrinsically complex, we want to look for a way to view the system in a way that we shed light on its behavior by looking at the problem in a simpler manner. This also has us not interpret Dr. Goldratt’s work in a manner he hadn’t intended.
Things should be as simple as possible, but no simpler. Albert Einstein
We are not looking for simple solutions. We are looking for a way to look at our problem so that the problem becomes simple and our solutions become effective.
Factors for Simplicity, Natural Laws and Actions
We should look at specific factors in order to have our view of our system be simple. We call these “factors for simplicity.” They can be considered the dimensions of our problem, that is, factors we can look at that enable us to understand our problem. For example, when building a bridge, one must consider the strength of materials (elasticity and compression), wind and a few other factors. These factors for simplicity will frame how to look at our practices. We can both see what happens when we don’t attend to them and we can see what we can do when we attend to them.
For each of these we also need an understanding of the natural laws that affect them (e.g., gravity). We can learn how to guide the actions we can take by understanding useful principles that can achieve our goals (e.g., Lean and Flow thinking). Part of this will be being able to measure how well we are doing (e.g., the value stream impedance scorecard).
In other words:
- Factors for simplicity provide us a way to look at a complex system in a simple manner
- Natural laws are present in the system and affect each component of the system and the relationships between the components
- We can learn principles of Lean, Flow and other methods to understand how to work with these natural laws
- We can organize solutions as sets of patterns so we can see how actions in one part of the organization relate to others
- we can create a collection of specific solutions that exist in these patterns so that we don’t need to re-invent the wheel but can still create solutions that are specific to our needs
The above list also provides insights into how FLEX and Disciplined Agile relate to each other – FLEX providing us with a powerful way of looking at the first four items in the list and with Disciplined Agile providing us with the wealth of options needed.
Why A Bias for Simplicity Is Important
In “The Choice”, Dr. Goldratt states “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?” The “devastation” results from believing a system is complex and then looking for sophisticated explanations for complicated solutions. It’s the search for sophisticated explanations that’s devastating – because simple explanations are available but not being investigated.
We already have a great deal of experience with a bias for simplicity. It is often called “intuition.” When we make an endeavor to discover this consciously, we become more adept at it and can greatly increase our understanding of what we need to do.
We need feedback, no matter how well we think we understand things
The potential of mis-understandings and other potentially chaotic (small error big damage) we must always get feedback on our actions. Therefore, however, confident we are, we must always be suspicious of our actions and use feedback to ensure we’re getting the results we want. We should also take the attitude that we are adding value when we learn.
If we don’t get the result we anticipate, we should ask why? It may be that we are in a part of the system that is unpredictable, but much more likely is there is a relationship that we either weren’t paying attention to or misunderstood. We can use the results we achieved (good or bad) to improve our understanding of the system.
By taking this attitude, is that even when we don’t get the result we want, our understanding always improves.
Using the Simplicity Factors to Predictably Get Good Results
In complex systems you cannot usually exactly predict what a solution to your problems will be. The intent is not so much to just jump to a good solution but to follow a path that will get you to one. The simplicity factors provide a mechanism for this:
- By looking at our system by attending to the simplicity factors we’ve identified – workload, efficiency, batch size, collaboration, management’s role, planning and quality – we can readily see what our greatest impediments are
- How we are violating the natural laws of Flow and Lean should now be apparent.
- We can now decide what solutions to try. It is likely that several impediments will have been discovered so we don’t want to try all of them. Doing so will not only cause cognitive overload but will make it if you’re really working on the most important things. Keep in mind that solutions further up the value stream have a greater impact on things later in the value stream than the other way.
- Implement what looks like a good solution and see what happens.
The two variables are 1, are we working on the right problem? and 2, do we have a good solution? We should therefore consider our approach as a three step process:
- look at our system through these factors for simplicity and come up with a plan
- attempt a solution which will often be correct, but which will, in any event, point us to a better solution or potentially what the key problem really ease
- adjust our solution.
Remember, the intent is not to be perfect but to get predictably good results.
A Short History About Getting to This Point
This section provides some insights by Al Shalloway for the interested reader about attempts to get here that, while somewhat effective, are not as effective as this.
I have long believed in looking at patterns. Christopher Alexander’s work, in particular The Timeless Way of Building, has had a tremendous impact on me. My ability to digest a lot of disparate information and make a cohesive theory has long enabled me to go into organizations and see both what is happening and what to do. Admittedly I’ve had a lot of training in this – mathematics, psychology, engineering and science. Some people told me I’ve just got a knack for it. But I’ve always felt that all I was doing was bringing my instinctual observations up to conscious decisions. This meant others could do this if they knew how to look at the problem.
My first attempt to do this was to have a few solutions under my belt to bring out. But as I noticed more patterns of solutions I realized I could create entire solutions from them. This led to what I called “the inflection point system” which was a collection of options for most all of the problems organizations faced in product development/maintenance that had a software component. This had a decent track record (about 50%). Some of its failings was due to people sabotaging it, but regardless of why, it was not providing clear answers at least half of the time.
I then looked for what I called “natural laws” of development. These were concepts like big batches cause problems, multi-tasking creates additional work. This was very effective. But it still had complex solutions to solve. It focused on making a better understanding of the solution, not a simplification of the problem. I was still looking for solutions.
When I first came across Dr. Goldratt’s inherent simplicity I misunderstood it to be the same as natural law view I was doing. But it isn’t. Dr. Goldratt’s intention for inherent simplicity is to create a simple system to understand by attending to it in a better manner. From here we can then look to see how to create solutions.
To learn more about Inherent simplicity, watch this four minute video – The role of the Thinking Processes of the Theory of Constraints by Dr. Eliyahu M. Goldratt