Canonical Scrum, screwing with Scrum

The Scrum community may be having problems defining itself, but Scrum itself has no such problems. Scrum in its canonical form is strongly sustained by Ken Schwaber and Jeff Sutherland, the originators of Scrum. There is no higher Scrum authority than these individuals.

I have been using the term 'canonical Scrum' for several years and I believe it is time to formalize what 'canonical Scrum' actually is. This article does that.

Details

"There is no standard Scrum implementation". These are words of Jeff Sutherland, circa 2008.

The statement really hit me and I thought about it for days.

And it is true- there is no standard Scrum implementation. Because Scrum is always applied to a preexisting and unique situation, the implementation is always adapted to the context. This is the realm of Scrum coaching.

The guide I use in tailoring Scrum is the 5 Scrum values--

Commitment, Courage, Respect, Openness, and Focus

I assist others in Scrum adoption; I am an agile/Scrum coach. If anything in my tailoring of Scrum violates any of these values, I know I am wrong.

Likewise, the next reality-check is the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

So long as you honor the 5 values of Scrum and honor the Agile Manifesto, you can (carefully) tailor Scrum to fit your context. But you had better make sure these checks actually do pass muster. You also better be very sure to refer to the Scrum Guide (found at Scrum.Org, see below)

Which brings us to what I call 'Canonical Scrum'. This is the abstract definition which exists before any implementing of Scrum takes place. It is the 'canonical' Scrum which is almost certainly never implemented without tailoring. It is the starting template that you hold up to your existing context, and tailor to fit. Canonical Scrum is the 'reference definition' of Scrum.

Canonical Scrum is like an abstract class in object oriented- it is meant to be inherited, not instanced. You CANNOT instance it. Instead you 'inherit' it and do some tailoring.

In object-oriented, you can define 'concrete' properties in an abstract class, properties that cannot be overridden- ever. The definition of canonical Scrum in the Scrum Guide defines things exactly this way!

In canonical Scrum, you have concrete, non-changable characteristics and properties: 1 Product Owner. Product Owner is 1 person, not a committee. 1 Product Backlog. Only the 1 Product Owner can edit the 1 Product Backlog. Etc. These are Scrum non-negotiables. But you can add to Scrum. You can add 1 day to the Sprint for defect fixes from the previous Sprint. You can tailor to fit. As it says in the Scrum Guide (November 2009):

When rules are not stated...figure out what to do...Try something and see how it works. The inspect and adapt mechanisms of Scrum's empirical nature will guide you.

So go ahead, add some things. Experiment. "THERE IS NO STANDARD SCRUM IMPLEMENTATION." Whatever you do, don't try over-riding the non-negotiable, 'concrete' properties of canonical Scrum. If you do that, you are screwing with Scrum, and implementing 'not Scrum' or 'Scrum but'.

Canonical: reduced to the simplest and most significant form possible without loss of generality. Source: Google

You can find the first canonical definition of Scrum in the book by Schwaber and Beedle. That version of Canonical Scrum was the reference Scrum definition for a long time. Since then Scrum has only a few changes.

You can find the current definition of canonical Scrum in the Scrum Guide (see below). One notable change is the explicit admonition against any 'Product Owner Committees'. You can do that, but it is NOT Scrum. "The PO is a person, not a committee" (Scrum Guide, November 2009, Ken Schwaber and Jeff Sutherland).

Another change is in the authority of the Team. In the earlier version of Scrum, the Team or the PO has the same authority to kill the Sprint. In the November 2009 version of Canonical Scrum, only the PO has that authority.

Authority is at the root of what Scrum is. The framework clearly defines the boundaries of authority for the PO, Scrum Master and Team. People new to Scrum find it amusing that the PO is not authorized to speak at the Daily Scrum. Experienced Scrummers know that the Daily Scrum is the Team's meeting, and that it makes perfect sense to de-authorize the PO when they are in attendance at this meeting.

In recent years, certain participants in the Scrum community have been vocal about tailorings to Scrum that violate the 5 Scrum values and yes, even the Agile Manifesto. There are those who want to populate the PO role with a committee, while still calling it Scrum. Meanwhile, vocal participants argue that no one knows what is actually "in" Scrum. Nothing could be further from the truth. It is very clear what is in and out of (canonical) Scrum. These details are in the authoritative Scrum document, which describes the content of Canonical Scrum. This document is the Scrum guide written by Ken Schwaber and Jeff Sutherland.

There is no standard Scrum implementation. At the same time, there is one (and only one) standard, canonical or "reference" Scrum definition. It is the simplest and most significant form possible. It is found in the authoritative Scrum Guide available for free downlaod at Scrum.Org.

Canonical: reduced to the simplest and most significant form possible without loss of generality. Source: Google

Links:

The Canonical Scrum Guide from Ken Schwaber and Jeff Sutherland, the orginators and sustainers of Scrum

***

Click here to examine MORE AGILE NOTES like this

Click here to return to the Agile Boston home page

Click here to return to the Agile CT home page

About the Author

Dan Mezick: An expert on teams and a trusted adviser to CxO-level executives worldwide, Dan consults on enterprise-wide culture change, implementing Scrum, and the often difficult adoption of authentic Lean principles. Learn more about Dan Mezick here.

He creates and teaches specific, useful tools and techniques for facilitating successful enterprise-wide adoption of agile and Scrum. Dan’s articles on teams and organizational dynamics appear on InfoQ.com, ScrumAlliance.org, and AgileJournal.com. Learn more about Dan Mezick's agile writing here.

He's the organizer of the Agile Boston user group and a 3-time presenter at Agile2007, 2008 and 2009, an invited speaker to the Scrum Gathering (Orlando) in 2010 and a news reporter for InfoQ.com

Reach Dan at:

dan.mezick [at] newtechusa [dotcom]

You can learn much more detail about Dan via his Agile Coaching page here.

Click here to examine MORE AGILE NOTES like this