The ONE right way to Scrum

What is the right way to Scrum?
This question is brought up a lot in organizations that are transforming to Scrum to improve their ability to deliver products. It's a natural question for smart people to ask when they are receiving Scrum training and then discover other teams adjusting from the "default" or "standard" implementation of their company's Scrum process.

Is there one way to do Scrum?

It's better to ask yourself, "should there be one way?"

When anthropologists talk of societies and biologists talk of evolution and virus colonies, history has shown that the results of monocultures are dangerous. The societies, governments, organisms, or colonies that survive are those that could respond to a change that wiped the others out. Having everyone thinking and agreeing all the time means new ideas aren't getting tried out. On the other hand, having only conflict/chaos means poor productivity/survival.
Computing monoculture
agricultural monocultures

What is Scrum?

Scrum has been around for over 10 years.  (You can read Martin Fowler's 2005 overview of Scrum in
The new methodology called Scrum)

Scrum says once the planning meeting has finished and the sprint starts, the planning conflict (conflict over resources) is over (or at least is moved outside the team) and the execution of the plan begins. For the team, conflict moves to technical implementation as they discover the best designs (test plans, class designs, craftsmanship) to meet the plan's goals. At the end, the team, ScrumMaster, and ProductOwner inspect the results and proposes a "new experiment" to improve software delivery.

What is Scrum (or basic scrum)

Three roles: team that does the project work, a ScrumMaster, and a single person to be ProductOwner.
A fixed backlog of work for a sprint.  A sprint is a fixed length of time.
A quick planning meeting.
Retrospective and sprint demo.
Daily standup meetings that are no longer than 15 minutes.

*Velocity, burndown charts, and task boards are also expected but aren't necessary for the empirical process other than adding more visibility. But since visibility is necessary, like a microscope is necessary to a biologist, I'm including them too.

You may ask six Agile Consultants "What is Scrum" and get six answers but I expect all six will have at least all the above.

Why six different answers?
How I Scrum today is different than how I Scrummed in 2006. How I Scrummed in 2006 is different than 2004 (my first Scrum project). But in all cases, I did Scrum. Before 2004, I did eXtreme Programming, and did not do all the above that is Scrum and instead did other things, XP practices (pairing, TDD, system test) and how my team executed those practices changed every month/year.

Why did my practices change? Because my teams inspected the WAY we did things and ADAPTED. We talked to and learned from others doing agile and tried out ideas for a sprint. Using the rigors of the experimental process (control/fix everything else but what you want to change, and then measure the results at the end) we decided what new adjustment to keep and what not to keep.

Standards

Should there be a standard way across an organization?
Are you saying that you want a monoculture? Is Scrum itself a monoculture? Maybe, but if each Scrum team is a little or a lot different so I think it's not a monoculture. I think that doing "basic" Scrum (just Scrum) as a standard is a good idea because then everyone from development to the CEO understands the culture enough not to:
Ask team members multitask across different projects
Ask POs to change the team's sprint backlog while they are in mid sprint
Discourage highly collaborative practices like Pair Programming
Discourage differences between Scrum teams
Ignore impediments discovered by teams

We want how we work together standard enough to not break each others' Scrum processes and to support teams' inspection and adaption of their own processes.

Directing an organization without standardizing a monoculture

Standardizing on organizational goals that allow teams to self organize is a good idea. Here are some I've seen in the industry:
burndown chart of some kind, definitions of done,
Automated system tests, automated unit tests, a system to show how many tests are passing/failing in the last hour, collocated teams, a highly visible team task board the team can use throughout the day, current code coverage and sprint by sprint history so we can see the trend.

The one TRUE way to Scrum

When an organization leaves Waterfall for Scrum, people need to be well trained on what is Scrum and asked to do things they are uncomfortable with, maybe even things they can't imagine could work. They need this pressure to get started doing Scrum otherwise, before even their first sprint, they decide to inspect and adapt to something they are comfortable with, Waterfall, out of a sense of comfort rather than out of quantifiable measurements that come out of the Scrum process (Velocity is a big one). So to get a team started, they will need to take a starting Scrum model on faith until they get the idea and see results good or bad. After a few Sprints, I expect to see that the cumulative affects of inspect and adapt to show some changes from their starting Scrum model but to still see the basic Scrum model intact.

If someone says that they have one true way to do Scrum, I'd start walking the other way because that person doesn't understand that Scrum requires teams to inspect and adapt their process to become efficient for their specific situation. If a team isn't inspecting AND adapting, then their Scrum process is broke.