Update: See the landing page for the forthcoming book Right to Left: The digital leader’s guide to Lean and Agile (published summer 2019, audiobook 2020)

Here’s a conventional, left-to-right [1] description of Scrum:

A Product Backlog (all the stuff we’d like to do), a Sprint Backlog (the stuff we plan to do this sprint), then a Sprint (a timebox) that culminates in a potentially shippable increment, a review, and a retrospective. Rinse and repeat.

To me, this is how NOT to describe Scrum. Is it a straw man, put up just so that I can knock it down? Hardly! Not all descriptions of Scrum follow this narrative, but it’s common enough. Complete with a video, here’s a nicely-produced example from a reliable source, the Scrum Alliance: Learn about Scrum (web.archive.org). It’s one of the first pages returned by Google in response to the question “What is Scrum?”.

The bullet points below are the first few from that page’s 30-second summary, and they’re very close to the commentary on the video:

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.

If you wanted to describe Waterscrumfall, would you describe it any differently? Perhaps “the team is arm-twisted into pulling an implausibly large amount of work into the sprint (or the project manager helpfully does it for them)”, but little else changes.  Would it help if the process description were prefaced with mentions of agility, complexity, and so on? That must depend on the reader’s frame of reference; if they don’t share our understanding of those words, they’re just noise.

Let’s try a right-to-left description, Scrum as a pattern of iterated self-organisation around goals:

A Scrum Team moves towards its Product Vision goal by goal, the team collaborating around a shared goal for a timeboxed interval called the Sprint, at the end of which the team reflects on how well the Sprint Goal was achieved before it prepares for the next one, organising around a new goal. The team’s best understanding of the work required to achieve the Sprint Goal is represented by a Sprint Backlog; options for future sprints are maintained in a Product Backlog.

The same process, yet so different, and with much less room for misinterpretation. This – I think – is much more like the Scrum that people love. Do you agree? Would you describe it differently?

Thanks to Steve Porter and Thorbjørn Sigberg for their feedback on earlier drafts of this post.

[1] Understanding Lean-Agile, right to left

Suppose you had to understand Lego – and I mean really understand it. Where do you start? With children playing, or with plastic feedstock?

Source: pixabay.com/en/plastic-polymer-granules-1061731/

Source: http://www.flickr.com/photos/aukirk/8171237624