In a recent post about Dealing with Complexity by Using Inherent Simplicity, @alshall makes a valiant effort to present Dr. Goldratt’s notion of Inherent Simplicity to the project management and agile communities.
I can only support this effort, because in those communities - and especially the agile one - there is an unwarranted overrating of the notion of complexity.
The adoration of complexity, unfortunately, creates a convenient laziness that breeds dysfunctional habits and behaviours. The mantras of “sense-and-respond” and “inspect-and-adapt” are taken for gospel, to the point of people shutting off their brains and like worms just sense their way through the darkness of complexity.
This is where Dr. Goldratt’s Thinking Processes can make all the difference. Now, mind you, “sense-and-respond” and “inspect-and-adapt” make perfect sense, if we truly are in the complicated, complex or chaotic domains, to use the categorization of Cynefin. This is were TameFlow’s Jungle-Jeep-Journey metaphor comes to fruition.
The problem is that most folks believe there’s only the Jungle and that nothing can be done about it.
As Al very well stated commenting Dr. Goldratt’s ideas in a couple tweets :
… it sounds like he [Dr. Goldratt] is saying that people should not believe reality is complex. But that’s not what he’s saying. He’s saying because they believe it is complex, they are looking for sophisticated explanations for complicated solutions. It’s the search for sophisticated explanations that’s devastating - because simple explanations (inherent simplicity) are available.
Al’s post starts asking the question:
How do we get an understanding of what will improve our methods?
It is a fundamentally important question. If we were to relate the same question with a small change making it closer to Dr. Goldratt’s thinking, we would probably ask the question like this:
How do we get an understanding of what will improve our reality?
Notice the reference to “our reality.”
The corner stone of the Thinking Processes is the construction of a Current Reality Tree (CRT) - something that appears to us as the reality in this current moment. The Thinking Processes will then invite you to develop a Future Reality Tree (FRT) to envision a future, improved state of reality.
Just the choice of words implies that reality is subjective and that can change in the course of time from a current state to a future state.
(Note: The Thinking Processes will also employ a number of other Logic Trees like Prerequistes Trees, Transition Trees, etc. which though are not relevant to the points here.)
Because we always start with an understanding of our current reality the way we think about that reality will determine how we proceed. If we are convinced that everything is submerged in complexity, then the agile mantras will be the only thing we will consider.
If we are convinced that there is Inherent Simplicity hiding away somewhere under this appearance of complexity, then - as Dr. Goldratt has said - we will have the stamina and endurance to uncover it. If we do uncover the Inherent Simplicity then we have a single point of action; acting upon which the entire system will be affected with enormous leverage - rather than having to wander in the dark trying to improve everything, everywhere, all the time.
Al’s post is right when introducing and framing the idea of Inherent Simplicity.
However, where Al is somehow departing from how Inherent Simplicity is understood in Theory of Constraints is that he then starts listing “examples” of Inherent Simplicity. Specifically he lists:
- Small batches are better than large ones
- The system people are in greatly affects their behavior
- Delays in workflow and feedback create extra work to be done
- People’s efficiency drops as the # of value streams they are in increases.
- You can’t manage what you can’t see
- Delays are caused when people do not collaborate
- Working beyond capacity creates waste
- Poor code quality creates unpredictability
It is in this generalization effort that we risk moving away from TOC’s encouragement to develop our own understanding of our current reality towards having a generic recipe or cookie cutter. I am not saying that this is what Al is suggesting - but that there’s a risk of that happening.
However, I fully understand how Al is reasoning because he is at heart a Pattern guy - and Alexandrian Patterns are also at the heart of TameFlow (see my forever work in process TameFlow Patterns book draft).
So I fully acknowledge the idea to categorize and find patterns.
Even the TOC has evolved towards something similar. Dr. Goldratt said that it is not sufficient to teach people to think and find the Inherent Simplicity within their own current reality. One must also give the means to act on that finding and to actually produce a positive change.
In the early stages the transitioning from the finding to the doing was achieved by developing and applying all the logic trees of the Thinking Processes. At later stages Dr. Goldratt recognized that there could be a generalization - which though did not result in cookie cutter recipes and not even patterns.
The generalization resulted in the so called Strategy and Tactics (S&T) trees - which were industry-specific generalizations of the logic trees.
Dr. Goldratt recognized that there were patterns of similarly structured and recurring Current Reality Trees and Future Reality Trees. So the logical relationships and casual relationships between relevant elements - for a specific industry - could be captured in such S&T trees.
Why does this matter?
Because Al’s post concludes with highlighting the importance of feedback. This is the essence of the Scientific Method. If reality is showing we are wrong, we shouldn’t strive to change it; but put more effort in developing a deeper understanding of reality. Or to use the saying: if the terrain doesn’t match the map, trust the terrain.
Feedback is important.
Can it be incorporated into a Patterns approach? From a TameFlow perspective, the answer is affirmative. The TameFlow Patterns and the resulting Pattern Language are structured according to cause-effect logic of TOC’s Thinking Processes.
And there is one very important element that comes out of the S&T trees: the Expected Effect. Any change that you might want to try out needs to have a well stated Expected Effect
As I state in “Tame your Work Flow”:
Expected Effects need to be detected categorically either through unequivocal observation or through effective measurement.
And as Al says concludes in his post…
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.
… which is the essence of being able to continuously improve.