there is more cause &effect in complex systems than there is in simple or complicated systems. It's just that the complex events that occur attract our attention. writing a blog now. this is very important insight. I've been saying this for 2 decades by not this clearly before
there are 4 types of cause and effects: 1) simple (obvious) 2) complicated (straightforward, but requires some thinking) 3) complex (can't been seen, made worse by coupling) 4) chaotic
The recourse for types 3 & 4 are:
* visibility
* feedback (to dampen affect)
* small steps
I'm not as interested in what type of system we have (all development is complex) as much as I am as to what type of cause and effect is present and how to compensate for bad reactions
Chaotic events can be spawned from simple, complicated or complex cause and effects
these are just anecdotal and illustrative. they are not based on data.
Consider, however, which events must be dealt with - and how.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
First, we need to take a scientific point of view. One of the implicit assumptions about this is that we can understand what’s going on. While many hide under the covers of our world is too complex to understand I agree with Eli Goldratt’s observation (picture) 2/
A scientific view means we recognize that we are always wrong, but that we’re always trying to be less wrong.
you don't want your framework to be purposefully incomplete. You want it to be intelligently incomplete. That is, you want it to provide you the information you need, when you need it, without overloading you.
you don't want your framework to be simple to understand but difficult to master. Although building product may be difficult to master, you want your approach to be simple to understand and relatively easy to master.
if proponents of an approach tell you it's like "playing a game" then make sure it's a game that works for you. And understand why the rules of the game are the say they are.
Quotes from Dr. Eli Goldratt's The Choice, These on the left deal more with complexity. Those on the right,
especially those in bold italics are most pertinent to this talk.
My point in including these is to show the relationship
between espousing things as being complex and causing resistance.
These quotes present a different mindset from what I normally hear about complexity in the Agile space. I believe
they each make a true statement that provides us with useful insights and which are consistent with my decades
of experience attending to complexity.
Will be writing a linkedin post on the J-Curve. here are some thoughts I'll be using.
Virginia Satir's J-Curve is held to be unavoidable.
I love Satir. But we're not a family.
But if we act like we're a CAS without understanding cause & effect we'll get it most likely. 1/
If we had a theory (like Flow, Lean, the Theory of Constraints) we could move the "transforming idea" up earlier & not have such a dip.
This is a belief that separates those in the Agile community. Read the text in the picture.
Scrum is on one side, Flow, Lean, ToC the other /2
we, of course, can't always be clear. but we can use resistance that comes up to see what to do.
Say we want to start using Minimum Business Increments. If teams can build in small increments this idea won't cause any problems.
The real cost of multi-tasking.
Many people point to multi-tasking as a major problem. It is a significant one, but not the key one. Consider the cause of multi-tasing – people working in multiple value streams. People are being interrupted and are interrupting others.
Correlated with multi-tasking is work waiting in queues. While multi-tasking may cause a 10-20% drop in efficiency, work waiting in queues can create unplanned work in the form of bugs, working on the wrong things, rework, etc., that is much larger.
Having people work in multiple value streams creates significant delays in the workflow.
And this causes waste.
This extra work is much more wasteful than the inefficiencies multi-tasking causes.