Simple Scrum

I think of Scrum as something almost impossibly simple that frequently gets over-complicated. It is the over-complication that tends to cause so much misunderstanding, leading to poor application. The following description of Scrum is intended to capture the spirit of simplicity.

Scrum is a framework for improving the way people do their work, or as defined on the Scrum Alliance site “a team-based framework to develop complex systems and products”. Scrum uses an iterative process where each iteration (aka sprint) is kept as short as sensibly possible, keeping to an even rhythm as it pulses through planning, execution and reflection. This strict, rhythmical, time-boxing aspect of Scrum provides an uncanny ability to unearth organizational dysfunction.

Scrum specifies three roles (ScrumMaster, Product Owner and Team), requires a prioritized list of work items, a goal for every sprint, and a simple way of measuring progress. Scrum uses timeboxed ceremonies to plan, to inspect/adapt on a daily basis, and to inspect/adapt on a sprint basis.

A clear distinction is kept between the “What” (the goal) and the “How” (the pathway). All parties maintain a continuous focus on the “Why”. Scrum requires clear focus, commitment and complete transparency at all levels; it embraces, or emphasizes certain human-centric values including (but not limited to) trust, integrity, courage and respect.

Roles
The Scrum Master is a servant leader to the team and a change agent within the wider organization. The Product Owner is the main voice of the customer, establishing a compelling vision and using a process of continuous prioritization to get there. The Team are a self-organized, cross-functional, empowered group who do the work, collaborating with the Product Owner as needed.

Artifacts
A backlog of requests, or goals is always maintained. It contains all the stuff (we think) we’d like the product or service to do, at any given moment in time. It is a living list, in a continuous state of flux yet always in a prioritized order, which will change over time. Items in the backlog always focus on the “What”. The sprint commitment is a subset of this backlog, sometimes broken down into work-tasks, which will describe the “How” of the product. Scrum requires simple metrics, e.g. measures of work remaining, or business value delivered. The metrics should be used to measure truth — not to measure success or failure. Only measures of truth can be trusted not to incite quick-fix behavior in a team

Ceremonies
The Team and PO meet before the start of each sprint to plan the work. The Team commits to prioritized items of work that have “well-formed outcomes” (the goal) and are expected to deliver finished, realeasable product to meet those criteria at the end of the sprint. How they do their work (the pathway) is solely their own concern. Every workday the team members meet around a visual metrics board (e.g. taskboard) to align with one-another and request and offer support. At the end of each sprint the completed work is reviewed by stakeholders and consumers, and adaptations suggested. Following the review the team members reflect on their process, seeking ways to improve and making commitments to change. Every Sprint produces an improved product or service and a more effective process.

This is more or less the description of Scrum that has been there since the first Scrum book was published in 2003. I have removed it from its software context, dropped some terms in order to keep the focus on the underlying principles and attempted to condense it to its essence. I have neither added nor removed anything.

25 responses to “Simple Scrum”

Hi Tobias,
Nice description. It also gives me a nice way of contrasting a Scrum and Kanban 🙂
Kanban says nothing about Roles, Artefacts or Ceremonies, but leaves the team to self-organise what works best. Instead, Kanban (as I describe it) suggests focussing on understanding the value stream, visualising it, limiting work in progress, establishing a cadence, and continuously improving.
This will often result in remarkably similar results, but achieved by a different route.
Karl

Great summary, Tobias. It complements the contents of your course very nicely. Simple is the way to go. You’ve started me on an interesting journey… and I hope to learn more. About roles, in particular, as well as on taking Scrum beyond the SW world.

I think you missed (or at least underemphasized) that the Sprint itself is timeboxed to 30 days or less. At the end of the sprint, the increment of value created by the team must be done (potentially shippable).

Every Sprint produces an improved product and a better, happier team.

Actually, almost everything in Scrum can be considered a logical consequence of these simple constraints.

Thanks Peter. I do say “Scrum uses an iterative process where each iteration (aka sprint) is kept as short as sensibly possible” But I think you’re right about emphasizing the commitment to completion, and continued improvement aspects of Scrum so I’ve made appropriate changes to the text. I trust it is a little clearer now.

Very nice Tobias. I particularly appreciate your emphasis on the separation of “what” and “how.” In my coaching experience, that is one of the most difficult conceptual hurdles to overcome, particularly in larger companies that have an entrenched defined-process culture.

Having been responsible for measurement, I completely understand the emphasis on appropriate use, and to be useful the truth must always be represented. However, I don’t agree with, and maybe I don’t understand, measuring “the truth” and not “success or failure”. I do not believe they are mutually exclusive. If I set a goal, and/or commit to something, I am either successful at reaching the goal or fulfilling the commitment, or I am not. In my coaching I have emphasized we will not always be successful, and we cannot advance or improve without failure along the way. If we hide or ignore failure we can’t learn from it and improve.

Hi Robert,
Velocity and Burndown in Scrum are measurements of how things are, not of whether or not we have “succeeded” or “failed” at something. These measurements tell us how we are performing, that is all. This empirical data can be useful in predicting future outcomes. If we set a goal, say “Velocity must be X points by Y date” we start to create behavior in a team that may not be desirable — e.g. the aim becomes to meet the metric, not to build the best software.

Hi Mayank.
I’m not sure what you mean by automating the Scrum process, but I’d caution against removing the human element from prioritization, planning and most other activities. There are many Scrum Tools that track burndown rate, etc. Some useful, most not. Did you check those out before creating your own? I’ll decline giving feedback myself, but suggest you send the templates to one of the scrum discussion groups, e.g. scrumdevelopment to request feedback.

But truth is that I’ve finally decided to take the CSM course, and I’ve received a mail from the CST with a pointer to selected readings, and among those is this post. Actually, I’m not attending because of CSM itself, but because I want to see Alan Cyment in action. I’ve been told he’s a great facilitator and that his CSM workshop is an enriching experience. I’d rather attend the “Spirit of Scrum” course Alan and you used to facilitate, but I haven’t seen the course scheduled any more!

Very nice and concise description of Scrum! Only one comment … I bought my first Scrum book in OOPSLA 2001 (the one with the colored letters, by Schwaber and Beedle). I thought that was the first Scrum book … ir is it considered non canon?