Process Frameworks in Complexity

Ordered Systems

David Snowden’s Cynefin Framework breaks ordered systems into two domains.

Simple Domain

Best Practice is a phrase often used, but it is only applicable in the simple domain of ordered systems.

Here proven methods work, such as ISO 9001. There is focus on process adherence and SOPs

We apply procedure and keep things simple. Cause and Effect is obvious. We tend to focus on resource optimization.

The Cynefin Framework suggests we Sense - Categorize - Respond.

Traditional leadership behaviors can work here. Some call this Command & Control leadership though it seems to be based on a mis-perception of military leadership to me. Leaders focus on behavior and context to get performance.

Complicated Domain

The Cynefin Framework suggests Good Practice in this domain. Here we apply skills and adaptive processes. We use expert judgment, systems thinking and Continuous Improvement.

Cause & Effect requires analysis in this domain.

The Cynefin Framework suggests Sense - Analyze - Respond.

Leaders should pull together groups of experts to participate. Leaders focus on competencies and behavior.

Disordered Systems

The Cynefin Framework breaks ordered systems into two domains.

Complex Domain

In the complex domain we need to use emergent practice. This is a different process model than we might be used to using. In the complex domain, we look for patterns. We run multiple small experiments to see what works. Patience is often needed for patterns to emerge.

Such multi-experimentation helps us detect patterns. Better than best practices here are the use of guidelines or heuristics. Simple rules let complexity emerge. For example, the army heuristic is "Move toward the sound of the guns."

Modularity (Chunking) can help in complexity.[1] Modular structures facilitate evolvability and adaptability.[1]

Because Cause & Effect can only be perceived in hindsight we don’t look for it in the moment.

In this domain we can focus on Flow Optimization. We can ensure our Process Library is enabling and adaptive.

Business Process Innovation is required in the complex domain.

The Cynefin Framework suggests Probe - Sense - Respond.

To probe, we can use iterative, fast cycles of testing ideas.

We can ask a question, form a hypothesis (expected results/observations) and test to discover what happens (actual results/observations).

When we’re done with experiments or data collection, then we have to interpret the data. Does the data oppose the hypothesis? Does the data support the hypothesis? Does it inspire revised assumptions?

In the complex domain, deterministic forms of prediction fail.

Leaders need to coach and focus on values and competencies. With large, open group discussion, we can get inputs from others.

We can benefit from experimental management approaches. We can increase communication and interaction.

Managers can actively support change initiatives and prioritize sustainable change. Leaders need to create other leaders.

In this domain, we optimize for the whole system and remove impediments. Much like Agile. We also need to enable insights to action quickly enough to matter.

Chaotic Domain (Random)

This is a bad domain to be in. Here only New Practices may work.

Leaders focus on stability-focused interventions and crisis management.

Cause & Effect not perceivable in this domain. We have to innovate to get out of this domain.

The leadership style best suited is charismatic leadership. Focus on Vision, Mission, Ambition. In crisis management, the leader makes quick decisions without time to reflect.

Focus on what really works, rather than looking for answers. The Cynefin Framework suggests Act - Sense - Respond.

The Theory of Constraints

Where should I improve first? Where should I focus? This question has caused people to lose sleep worrying about where to apply limited resources to make a significant improvement to their flow of products or services.

The good news is that there is an answer. Dr. Eliyahu M. Goldratt developed his Theory of Constraints and described it in his popular book, The Goal, by Eliyahu Goldratt and Jeff Cox. Goldratt later credited Toyota and Lean as his foundation for the Theory of Constraints.

To help organizations profitably succeed, the Theory of Constraints aims at increasing throughput, reducing inventory and reducing operating expenses.

We see constraints or bottlenecks in play daily in commuting to work.

Figure 1. A Traffic Jam is a Bottleneck or Constraint on the Flow of Cars on a Highway

To apply the Theory of Constraints to knowledge work, we also have to think of partially completed work inventory. Work in progress (WIP) is inventory in both manufacturing and knowledge work like software engineering. Just like manufacturing, in knowledge work excessive inventory is a expense, not an asset. Inventory is bad. Agile Kanban (as opposed to manufacturing kanban) is based on this idea too.

The Theory of Constraints is a way of identifying the main limiting constraint, or bottleneck, in a process and then systematically improving that constraint to increase throughput. This is the path to getting the most improvement for the least investment of resources.

Rather than flowing cars on a highway, the next Theory of Constraints example shows work items on a Jira board or other team board. The following image is from Hacker Noon.

Figure 2. A Software "Traffic Jam" or Bottleneck or Constraint


The Theory of Constraints aims to help us answer five big questions:

  • "What needs to change first?" (the weakest link in the process 'chain')

  • "What should it be changed to? What is the To-Be state?"

  • "What actions will cause the change?"

  • "Did the change improve throughput, inventory or operating expenses?"

  • "What needs to change next?" (the next weakest link)

The Theory of Constraints also accounts for complex adaptive systems with many linked activities. It provides the following:

  • A way to identify and eliminate constraints

  • Thinking tools for problem solving (root cause analysis reality tree diagrams, 5 whys, etc.)

  • A way to prioritize improvement actions on one main constraint at a time

  • Compatibility with Lean and Agile

  • Reduction or elimination of bottlenecks resulting in less work in process (WIP)

  • Improvement of overall organizational profit, rather than sub-optimizing at a lower level


The Theory of Constraints consists of five steps:

  1. Identify the constraint (or bottleneck)

  2. Exploit. Improve what you can with what you’ve got aiming to increase the throughput of the constraint (Do better without additional investment)

  3. Subordinate. Subordinate the rest of the process to the constraint or bottleneck. Don’t let other process steps go faster than the bottleneck.

  4. Elevate. Do what you can to improve the constraint further.

  5. Repeat. Look for the next bottleneck. Kaizen. Continual improvement.


Use Goldratt’s Theory of Constraints to focus Lean efforts on the priorities that matter to the business or enterprise.

There is no point to improving areas in a flow that are not the constraint because the bottleneck is the limiting factor on the flow of value to the customer in your value stream.

The following image is from Just Plan It, shows this well.

Figure 3. Improving the Constraint Improves Throughput, Not Improving Other Areas

Note the original constraint was improved, the flow widened, and then it was no longer the constraint. Another place in the value stream is the new constraint. Rinse and repeat.

I have used the Theory of Constraints successfully over a decade and strongly recommend it.

For more information, contact The Theory of Constraints Institute.

Theory of Constraints Thinking Processes

I have begun using the Theory of Constraints Thinking Processes. Specifically current reality trees and future reality trees.

These are not new. I had to buy a paper copy of Thinking for a Change, Putting the TOC Thinking Processes to Use, by Lisa J. Sheinkopf because there was no ebook. They did not make ebooks back in 1999. I’ve also been listening to the audio book of It’s Not Luck, by Eliyahu M. Goldratt. It was published in 1994, but is still applicable today because using our brains has not changed much the 25 years since Goldratt published this book. Goldratt’s book is in a novel format with a story that blends in how to use the techniques.

His story is engaging, but it is hard to apply from that format. Lisa’s book is much easier to look up how-to information.

Anyway, these processes work well. They take time to create, but are easy to communicate to others once drawn out.

I’m using a UML editor to create the diagrams.

The processes are listed below.

  • What to change?

    • Current Reality Tree

    • Evaporating Cloud

  • To What to Change?

    • Evaporating Cloud

    • Future Reality Tree

    • Prerequisite Tree

  • How to Cause the Change?

    • Prerequisite Tree

    • Transition Tree

The sales presentation example in It’s Not Luck using these tools was quite good.

Lean Principles

Lean is not a tactic or a cost-reduction program, but a way of thinking and acting. Lean thinking puts forward the idea of all of the processes forming a value stream, like a water stream, creating value that keeps flowing downstream to the customer as quickly as is sustainably possible with as few eddies, dams, or other wasteful slow downs or stops due to obstacles. The short list is:

  • Identify the current customer Value.

  • Visualize the whole product development process (value stream).

  • Reduce Waste along entire value streams.

  • Create Flow ( Batch Size Reduction).

  • Establish Pull (Just-In-Time Production).

  • Respect People.

  • Amplify Learning (we use Scrum Retrospectives).

  • Seek Perfection ( Kaizen, or get a little better each iteration).

  • Lead Lean.

The following longer list includes some clarification about what is meant by each principle.

Clarification of each Principle

This section clarifies what is meant by each Lean principle.


Identify current customer Value

  • The customer will pay for it.

  • Perform work right the first time.

  • Specify value from the perspective of the end-customer.

  • Create more value for customers with fewer resources.

  • The customer changes over time, what satisfies them now may not later.

Value Stream

Visualize the whole product development process (value stream).

  • Figure out how the work gets done.

  • Use visual boards to display necessary status and progress information at a glance.

  • Optimize communication with frequent (daily) short (15 min) scrum meetings in combination with the visual Kanban board.

  • Use visual signals and cues.

  • Anyone can see work in process (WIP) easily if they have access to the Kanban board.

  • Align the team through simple visual communication.

  • Apply queuing theory.

  • Visual project management has been described as the ability to understand the status of a project in 5 minutes or less by simple observation without speaking to anyone.


Reduce Waste along entire value streams.

  • Recognize the types of waste Lean identifies.

  • Whenever possible, eliminate those steps that do not create value.

  • Develop processes that require less capital, physical space, human performance and time.

  • Create the ability to respond to changing customer value quickly at low cost.

  • Make information management much easier and more correct.

  • Establish value as seen by the customer to distinguish value added from waste.


Create Flow ( Batch Size Reduction).

  • Create flow by reducing and eliminating waste.

  • Deliver as quickly as possible.

  • Interruptions in the process steps degrades the flow of buyer/customer value in the value stream—​To achieve smooth flow, reduce interruptions.

  • Too much work in process (WIP) creates delay waste due to context switching.

  • Reduce batch sizes to reduce the amount of WIP inventory.

  • Cycle time is almost directly proportional to the amount of WIP. Multitasking is an illusion.

  • Smaller batch sizes shorten the overall production cycle time.

  • Inventory turns (velocity) increase as we shorten production cycles. More turns allow operating profitably at lower margins.

  • The ideal flow is "one piece flow" (finish one work item before starting another one).

  • Create a level or smooth development process flow (decompose work effort into similarly sized work items).

  • Assess the value stream to make sure each step adds value, can make the desired result, that resources are available and adequate.

  • Organize so all the expertise needed to produce the product/service is on a cross-functional team rather than in traditional (functional) departments.

  • Integrate suppliers in the product development process.

  • Synchronize any simultaneously executing processes.

  • The fixed iteration time box/tempo of iterations keeps a sense of urgency and effectively sets the team cadence.


Establish Pull (Just-In-Time Production).

  • Only pull the amount of work item cards you can do (pull less than or equal to the WIP Limit). Often this is 1-2 per person.

  • Be accountable for work items you pull.

  • Use pull-based OJT training for development team members rather than push-based training all at once.

  • Build the required work item when it is required.

  • Downstream customers pull value from the preceding upstream activity, setting the pace.

  • No one upstream in the process should produce a work item until a downstream customer asks for it.

  • Less time is wasted building unsalable product.

  • Reduce or eliminate bottlenecks.

  • Pull is sometimes described as just-in-time.


Respect People.

  • Focus on process fixes first before seeking to blame people on the team.

  • Make the pace of work sustainable indefinitely—​too much overtime adds risk.

  • Use lessons learned during retrospective meetings—​a culture of blame constrains innovation, while collaborating how to do better supports improvement.

  • Let the people who do the work figure out the improvements each iteration.


Amplify Learning.

  • Over time, teach Lean thinking and skills to everyone involved.

  • Use short iteration cycles to speed the learning process.

  • Learn what to improve by increasing feedback using short feedback sessions with customers.

  • Use the Lean language so communication is efficient—​All involved learn it.

  • Seek progress allowing for some mistakes as you learn.

  • At the start of the product design process, thoroughly explore alternative solutions while there is maximum time available for design.

  • Prevent accumulation of defects by running quality assurance content checks and functionality testing as soon as the content is written or the functionality is working.

  • Share effective improvements between teams on large projects.


Seek Perfection ( Kaizen, or get a little better each iteration).

  • Speed up PDCA (Plan, Do, Check, Adjust) cycles.

  • Improve the way projects are executed.

  • Focus on root causes not symptoms.

  • Build a culture to support excellence and relentless improvement.

  • Use standardization to create broader flexibility.

  • Build in continuous improvement and team learning.

  • Build in quality. Design processes, products and services to eliminate errors rather than inspecting work at the end of the process to make sure we find all errors.

  • Tailor technologies to fit your people and process where possible.

  • Get everyone actively engaged in operating the value stream correctly per the latest improvements.

  • The team looks for any lessons from failures.

  • Continually challenge the status quo.


Lead Lean.

  • Change from so called command and control style of leadership to leadership based on questioning, coaching and teaching and rooted in the scientific method of PDCA experiments.[1]

  • Read the respect people section again.

  • Engrain respecting people into leaders at all levels.

  • Track numbers and manage by evidence.

  • Lean leaders lead from gemba, where the action happens.

  • Apply the 3 "gen" or actuals:

    • genchi--(like gemba) go to the actual place.

    • genbutsu—​observe the actual product, process or service.

    • genjitsu—​gather actual facts.

  • Ask open-ended, probing questions.

  • Plan in more detail only when you get closer in time to doing the work (like rolling wave).

  • Unanticipated events occur during project life cycles.

  • Decide as late as possible, particularly for decisions that are irreversible, or at least will be impractical to reverse.

  • Minimize project administration.

1. The Lean Enterprise Institute, Inc. (LEI), Lean Enterprise Institute, Inc., Cambridge, MA,, See