Scrum: Just do it!

Myth: Understanding is optional. You'll learn by doing.

Variations:

• Trust me, I'm the coach.
• You don't need evidence.
• It's true even when there is no evidence.

Follow-up myths:

• We're doing this agile thing.

Category: General Scrum myths
Danger: High

The basis of the myth

At this time, I can not trace out a specific origin of the myth.
Time and again, bad coaches come loaded with a "toolbelt"and want to install this toolbelt in an organization. Being superficially familiar with these tools, they are neither aware of why these tools exist on in which circumstances they are applicable. When asked for tracible evidence or a clear line of reasoning, they start to evade.
This applies to Scrum as a whole as well as Scrum-specific practices (such as burndown charts).

While there are indeed times when urgency dictates not dicussing things out beforehand, that should not be the standard scenario and used with caution. It should never be a retort strategy.

Why is it a myth?

The basic premise of "Just do it" is in contradiction to the Scientific Method. Scrum is, at it's core, an empirical process improvement framework. Empiricism relies heavily on the Scientific method.

Assumption #1: Superior intellect
"Just do it" assumes that the problem and solution are well understood by the suggesting person, but not at all understood by the team. The person claiming "Just do it" is claiming intellectual superiority over others, as they believe their stream of reasoning is beyond the ability of others.

Assumption #2: Future evidence

In the absence of evident proof, "Just do it" is used to conjecture "The proof will be there later". For innoative empirical experiments, the discovery of proof is part of the process. However, when discussing common agile practices or even core Scrum, there are hundreds of thousands of people who have done the same thing before. Providing a tracible line of evidence should be a very simple exercise. 

Assumption #3: Telling = Learning

Some people like to be told what to do. However, when a person asks for evidence, telling them what to do without explaining what the expected outcome of an action is, this might be a direct attack to that person's behaviour. Ideally, the team would figure out before an experiment why this experiment might be a good idea, then come up with a change design to come up with the expected result. When providing a method without introducing the reasons, this learning process is broken. 

Consequences

Change failure

Introducing a change without transparent reason or tracible evidence decreases the likelihood both of succeeding with the change and obtaining the desired outcome. In addition, people lose the opportunity to reflect on the benefits of the change when the change approach is intransparent. 

The likelihood that people can succeed with the next change independently decreases.

Wrong mindset
Empirical process management relies on observation, evidence and critical evaluation. When a Scrum adoption already starts without evidence in place, it will be difficult to foster an evidence-driven mindset.


Wrong understanding of Designed Eperiments
The art of experimental design is to find the most feasible solution to move from state X to a desired state Y. Ideally, the unknown area between X and Y is insignificant, in which case the change is most likely to succeed. Never should an experiment be designed with "unknown outcome". That is haphazard. Available evidence should be used to reduce the unknown as much as possible. Suggesting that evidence is not required puts scientific experimentation into the realm of mucking around and fiddling.

"You just need to do Scrum, you don't need to understand it" is a surefire way of creating Cargo Cult Scrum that is unsustainable from the start.

Remedies

The introduction of Scrum is a huge disruption. Aside from the introduction of artifacts, roles and ceremonies, the organization will undergo massive change. A Scrum coach should be familiar not only with the target state of Scrum, but also be able to produce evidence of why this state is beneficial.

Providing requested evidence supports credibility of the change. It also reduces the risk of lacking understanding of the consequences. Additionally, teams and members of the organization will be able to examine this evidence as part of learning to apply the Scientific Method to their own processes. They will discover ways of comparing the evidence in their own organization against the evidence presented, drawing parallels and exposing discrepancies.

Fostering this scientific mindset is significantly more imporant that "doing proper Scrum". Except when there is a risk of irreversible damage, a coach should strongly resist the urge to tell anyone to do anything, regardless of how wrong they're using Scrum now.
When fast change is needed, providing tracible evidence about the future state is better than telling an approach.
When slow change is feasible, providing tracible evidence about the current dysfunction is better than suggesting an approach.