if you're smarter than someone who has had decades more training and experience than you then what are you not smartest in? Challenging experts is always good if you're trying to learn something. But recognize who is probably right while you're learning.
This goes for everywhere
the exception to this is when there's a mindshift involved. So when 5% disagree w/95%, one should look to see if the 5% are coming from a different place. If so, worth examing that diff. For example, Agile started out with a minority, but was based on different undrestanding
however, when two disparate groups are interpreting the same data with the same science and one side has 95% agreement, they are virtually always correct. When the 5% has been correct they've been able to make more accurate predictions as to what's going to happen.
i've been talking generallly here, but if you apply this to Covid and the environment, you'll see that the 95% have been making accurate predictions while the 5% have not.
cases of where small minority (or individuals were correct): 1) Semmelweis 2) Marconi 3) Mendel 4) Copernicus 5) Keppler
in all cases a new theory was introduced.
• • •
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.