The Systems-Thinking View of Simple, Complicated, Chaotic, and Complex

December 2, 2017 — Posted by Al Shalloway

This page was moved to here as part of our FLEX (FLow for Enterprise Transformation) site.

Understanding the challenges present in changing behavior is important.  There has been a lot of conversation about simple, complicated, chaos and complex events.  While discussed by many, some of these discussion ignore three salient points:

  1. The relationships are often not inherently the way they are but are that way because of limited understanding
  2. Chaos is a result.  We should be discussing ‘chaotic events.’
  3. All of this needs to be taken from a systems-thinking point of view. 

First, some quick definitions

Simple means there is a well defined relationship between an event and the resulting action from that.  Dropping a pen and seeing that it will fall is a simple relationship.  Or, if one wants more accuracy, there may be other factors (such as wind velocity) taking it out of the simple domain. Doing this in space may be a more complicated relationship.  Hence, relationships may be simple but not in all contexts.

Chaos is a result, not an event. Its definition is “complete disorder and confusion” as in “snow caused chaos in the region.” It can result from behavior so unpredictable as to appear random, owing to great sensitivity to small changes in conditions.” 

Chaotic event is an event that is unpredictable even if there is an underlying science.  The “straw that broke the camel’s back” and the “butterfly effect” where a butterfly flapping it’s wings in Asia can theoretically cause a typhoon on the west coast of the US.  These are often called “non-linear” events since a small change may cause a large change.

Complicated events are when there are several well-defined relationships between cause and effect.  If all of these relationships are known then we can predict the outcome of the actions.  Launching a rocket is an example of complicated.

Complexity means that the exact relationships between things are neither known and possibly unknowable.  Complexity does not mean general predictions can’t be made, but that exact predictions cannot.  For example, weather is complex, but there are patterns to weather we can learn.

Different between inherent nature and what we understand.

Many things that appear complex in the past were really just events for which we had no understanding.  See Complexity Is Not What it Used to Be for an example of what appeared to be complex, was solved by someone, but couldn’t get it adopted because of the lack of understanding.

Chaos is a result.

While chaotic events, by their very definition, can’t be predicted, they can be controlled.  This is the driving force for quick feedback.  We can always introduce errors into our system. If we can find them quickly, we can eliminate most of the impact of the error.

Taking a Systems Thinking Point of View.

Systems-thinking provides us with two main tenets:

  1. We must recognize that all of the parts of a system are interrelated and that changing part of the system affects it all. Furthermore, the system is not the sum of the whole but exhibits its own behavior.  See What if Russ Ackoff Gave a TED talk.
  2. The system affects the behavior of the people in it in a very significant manner.

What this means is that a system likely exhibits all 4 types of events: simple, complicated, chaotic, and complex.  And definitely all four if people are present in it as people’s behavior is complex.  See People Are Complex, Software Development Isn't

What This Means

When a transition to new methods is attempted, the actions being attempted become part of the system.  This is why one should consider the effect of following a  particular approach will have on your organization.  That is, include people's reaction to Scrum, Kanban, Kanban Method, SAFe, FLEX, DAD, LeSS, …The method you are using becomes part of your system. This should be accounted for in the design of your approach.  Many approaches take a different attitude about how they will/should affect the system.  For example, Scrum suggests that impediments to doing Scrum should be removed.  This works in some contexts, but not so well in others.  Lean suggests taking a systems thinking point of view so that any adjustments to your workflow must consider the value streams being affected.

If you want to learn more about how we attend to systems-thinking in transformation, look at our FLEX system on our portal

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban