i was surprised to see an audio by Ken Schwaber on the Dangers of customizing Scrum.
Instead of espousing against modification you'd think there'd be a discussion on how to lower the risks.
will be writing a page on random thoughts regarding the difference between SG Scrum (Scrum guide based Scrum) and DA Scrum (Lean/Flow/ToC based Scrum).
The biggest one is Scrum being based on values and practices with no theory and DA being based on theory that enables choice.
A DS SM can start a team with Scrum if that's appropriate (just choose the Scrum options). But then can deal with any lack of fit for purpose. Might take more for the DA SM to learn how to do this, but no more for the team.
• • •
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.