Dealing with Complexity by Creating a Bias For Simplicity

From the Manifesting Business Agility Blog
by
This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.

About this Blog

RSS

Recent Posts

Are You Working on Your Problems?

Dealing with Complexity by Creating a Bias For Simplicity

Using Inherent Simplicity to Guide Your Actions

Why to use the word capacity instead of resource when referring to people

Why Teams Should Have a Tailored Approach for Adopting Agile



Note that this is taken from a book I'm writing on FLEX. To see the latest version go to Dealing with Complexity by Creating a Bias For Simplicity. Please comment here, however. 

 

It is difficult to make predictions, especially about the future. – Mark Twain

Wrote that for every complex human problem, there is a solution that is neat, simple and wrong. - H. L. Mencken 

Looking at Complex Problems in an Effective Manner

How do we get an understanding of what will improve our methods? Product/service development/maintenance is very complex. 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. 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
  • There are ways to look at a complex system that makes it easier to see what changes might be beneficial
  • No matter how well we think we understand our system, we must recognize there is no guarantee we understand how it will behave.

Why it's hard to make predictions about whether a change will be beneficial

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 Mars polar lander where different units of measure were used by different development groups
  • people will exhibit unpredictable behavior at times for no rational reason
  • a degree of unpredictability that is just inherent in complex systems

Inherent Simplicity

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 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.

Some of these are:

  • Small batches are better than large ones
  • The system people are in greatly effects their behavior
  • Delays in workflow and feedback create extra work
  • People’s efficiency drops as the # of value streams they are in increases.
  • You can’t manage what you can’t see
  • People not collaborating well creates delays in work flow which creates additional work
  • Working beyond capacity creates delays and waste
  • Poor code quality creates unpredictability

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.

A Warning

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

We should look at specific factors in order to have our view of our system be simple. We call these "factors for simplicity." These factors are useful because they both illustrate what I'd call "natural laws" explaining what's happening as well as enable us to see relationships between them. A natural law is something like gravity. It is, what it is. By attending to it our actions will be more effective than if we don't attend to it. But natural laws often interconnect in complex ways and being able to see them does not necessarily mean we can view our system in a more coherent, simpler manner .

 

 

What to avoid

Factors for Simplicity

Potential solution for improvement

 

What to strive for

Large batches

 

Batch Size

Smaller batch sizes are generally good but one must attend to transaction costs of handling them as well.

Use Minimum Business Increments (MBIs)

 Small batches
Viewing individuals and/or teams as components

Attend to the effects of the system on people

People are significantly effected by the system they are in.

Systems inform behavior.

Use systems-thinking

Viewing the system as a whole
work is mostly in a waiting state than in a working state

Delays in workflow

Delays in workflow create work you must do but which does not add any value to the customer.  Eliminating delays eliminates waste.

Delays caused by too much work, poor collaboration, poor relationship between work and how people are allocated to it.

Look for handoffs, handbacks and size of queues.

Create cross functional teams to the extent possible. Avoid overloading people.

work rarely waits
long delays

Delays between making an error and detecting it.

Delays in feedback both makes it more expensive to fix detected errors while cascading waste to others

Achieve flow. Use test-first methods.

no delay

Many value streams

 

Number of value streams people are in

People should not be in so many value streams that they can’t finish a request from one before getting a request from another.

Have people be in one value stream or make it clear how being in multiple value streams causes problems.

One (idealized)

Work not visible

Delays not visible

Agreements not made or not visible

Degree of visibility

People can’t manage work unless they can see it.

People can’t collaborate well unless what they are working on is clear and how they are working on it together is clear.

Make all work and agreements explicit.
Agree to the Guardrails.

Work is visible

Delays are visible

Agreements have been made and are clear

More work enters the system than there is capacity for

Work entering the system is not visible

The amount of work entering the system

If too much work enters the system the value streams are almost certainly going to be overloaded.

Have a controlled intake process that uses pull methods to allow for controlling the level of work. Follow the mantra – “stop starting and start finishing.”

The right amount and right size of work is started.

Work entering the system is visible

Work is well beyond capacity

How close to capacity are people working?

Manage work in process both at intake and throughout the value stream

Manage the work entering the system

Lower multi-tasking which lowers the capacity of people

Work is below capacity
Handoffs and handbacks occur frequently

Number of handoffs and hand backs

Handoff always result in both a loss of information and create the risk for unanticipated delays that cause unplanned work.

Use cross-functional teams and operate multiple teams in a common cadence with frequent integrations.

“Flow when you can, pull when you must

Few handoffs or handbacks occur
Low product quality

Product/service quality

Product/service quality refers to both how fit for purpose the product/service is and how well it has been designed and implemented.

Use verification (test-first) methods.

High product quality
Poor collaboration

How well people collaborate

Collaboration is a critical aspect of removing delays in workflow and getting quick feedback.

Achieve cross functional teams.
Make agreements on how people will work together

Good collaboration
Test after build

Relationship between build and test

If testing lags building errors will be detected late.

Use verification (test-first) methods.

Building and testing are concurrent.

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.

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

Posted on: December 04, 2019 11:51 AM | Permalink

Comments (8)

Please login or join to subscribe to this item
Hi Al

I think this post is important as it strives to build bridges between the project management / agile communities and Theory of Constraints. Something I've be striving to do for the last decade.

I wrote a longer commentary about it here:

https://community.tameflow.com/t/complexity-and-inherent-simplicity/229

Feedback is appreciated.

Dear Al
Interesting approach to the topic
Thanks for sharing

I liked: "Discover simplicity and use simplicity"

Al - Thanks for sharing these insights. All really great points. Thank you!

Steve - yes, this is very much what it is for.
If you read our Guardrails (agreements people make on how to work together) you can see a parallel between the inherent simplicity in a development group and the agreements people should make.

Link to the Guardrails
https://portal.netobjectives.com/pages/books/achieving-business-agility-at-all-scales/the-guardrails/

Hmm
I'm unconvinced of conclusions that say complexity is addressed via simple solutions.
I've little objection to most of the individual points
The focus feels drawn narrowly to be systems development while the topic needs to be holistic operations through times of stability and change
While I'm sure of human ability to achieve results in ways that the achiever cannot articulate (tacit knowledge not codified as explicit) I'm still concerned about dismissal of complexity on the claim of intuition
My definition of something that is done by intuition is simplicity. Simplicity is imho ability to map cause and effect that doesn't have to equate to verbalising
I'm more sympathetic with approaches to the delivery of intention in complexity environments that follow von moelk and clausowitz than "small batch size"

Simon - thanks for your response.
I am not suggesting that complexity is address via simple solutions. I am suggesting there are simple ways of looking at your problem that has it not being complex in your understanding which then results in simpler solutions.

Much of the Lean principles that result from this line of thinking actually derive from von Moelk and Clausowitz's work.
See Certain to Win and The Art of Action.

I love this blog. Thanks Al for sharing your insights, very helpful.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"The only difference between me and a madman is that I am not mad."

- Salvador Dali

ADVERTISEMENT

Sponsors