"How I Read the Scrum Guide" by Mike Burrows

Translation

1. The Good: Things the Scrum Guide reinforces that can easily get lost

My biggest “Aha! for Scrum was when I realized it wasn't about story points, velocity, Fibonacci numbers, and the like. While tools like these seem to work well enough for some people, others see them as a recipe for (i) wasting time or (ii) setting teams up for regular disappointment, making them a target popular to be sniped. Fittingly, there is no mention of them in the guide.

The guide instead speaks of the sprint backlog as both a set of selected sprint items, and – crucially – a plan for producing them. And understand: the sprint backlog is subordinate to something else, the sprint goal:

As the Development Team works, they keep the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different from what the Development Team expected, they work with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint.

Imagine working in an organization that typically takes months or even years to deliver anything of note (I'm not exaggerating). Now give people a chance to work together on achieving a meaningful goal in a matter of days. And even. And even. It's powerful. Could this be done without Scrum? Does this happen without Scrum? Of course it could be done without and of course it happens without, but Scrum is often a vehicle through which people experience this for the first time, and that's something to celebrate.

I also have to give credit to Ken and Jeff for being explicit about the applicability of Scrum:

Scrum (n): A framework in which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

I'm not emphasizing this quote as some sort of flippant compliment, a way to put Scrum back in its box. The area described here is huge! And this is important for reasons we explore in Chapter 5 of the Agendashift book. To implement a meaningful Lean, Agile, or Lean-Agile process, you must embrace the idea that the often challenging, sometimes messy, and always necessary work to help an organization change must be treated as real work. , not just alongside the production work, but integral in itself. The "adaptive complex" part of this quote doesn't necessarily sound like jargon, but it refers to the inability of a linear plan to deliver this type of vital change effectively (see my keynote “Change in the 21st century”)

Putting these elements together, a well-functioning Scrum means:

1. Significant goals achieved regularly
2. The system – the team and beyond – evolving proportionally

It's harder to pull off and even harder to maintain than it looks, and the guide is honest about the level of challenge involved. What he fails to say is that as soon as Scrum comes to mean plowing through the backlog, those benefits become harder and harder to maintain. This is why there is support in complementary tools such as Kanban, Lean Startup, and now Agendashift [1] when the feedback from Scrum itself begins to dwindle.

2. The villain: things that should not be accepted as they are

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand the theory, practices, rules, and values of Scrum.

The Scrum Master is a servant leader for the Scrum Team. The Scrum Master helps those outside of the Scrum Team understand which of their interactions with the Scrum Team are helpful and which are not. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

There would have been so many better ways to introduce the role of Scrum Master, and it's inconceivable that this section could have been edited out (again) in the 2017 edition and left as it is. After a nasty, easily constructed paragraph like 'your first responsibility is to Scrum', we see a kind of very carefully limited servant leadership that will surely be read in light of what precedes it. There are more charitable interpretations, but they depend on assumptions that are not made explicit.

To be a true servant leader, your responsibility is to your colleagues, your organization, your customers, other stakeholders, even to society. Where Scrum literally helps you with these responsibilities, fantastic. Where it gets in the way, it seems like it's time to do something not literally. A true Scrum master might find these situations rare, but pity the doubting newbie! Even if only in the context of these phrases, if you don't mind Scrum Masters getting certified after just 2 days of training, you should.

If we want our industry to do better, we have to look at its systems, ready to challenge a status quo that tends to preserve itself. Scrum has been around long enough to qualify for this kind of scrutiny, and whatever their true intent, these widely read phrases are too open to cynical, self-interested interpretation.

In response to my tweet yesterday morning, Neil Killick was quick with this much better alternative:

[Translation of Tweets]

mike burrows

Neil Killick

With all due respect to Neil, it wasn't that hard, was it?

3. My approach

I start from the perspective that Scrum describes pragmatic solutions to common problems. Do you have several clients, far from the team? So you will find it useful to have a Product Owner who is widely available. Do you need someone to model and facilitate appropriate practices and behaviors? So get a Scrum Master on board. Are your feedback loops too slow for the rate of environmental change? So plan your work to fill small timeboxes and meet daily.

Conversely, if you don't have all of these problems, you might not need Scrum. At the very least, proceed with caution:

• Don't put barriers between a team and its customers if they're already collaborating (yay, manifest values!)
• Don't add layers of process and ceremony when the team is already effectively self-organizing
• Don't let Scrum's timeboxes get in the way of rapid flow and rapid change – they don't need them [2], which is why I don't present them as a technical objection to Scrum

These are cool problems to have, you might tell me. And truth be told, that's why I'm much more pro Scrum than anti. But I don't leave my experience, my knowledge or my curiosity at the door. Where I see conflicting approaches, I dig deeper, fully expecting to find agreement, and am usually rewarded handsomely.

For the most part, you can leave out interested items (I learned how to filter them out). If you help bring clarity and agreement around purpose and objectives (things Agendashift and the guide fully agree on), and if you start with needs, seek agreement on outcomes , and so on [3], chances are you're approaching things the right way. Over time, you'll find things will sound less and less like what you heard in class, but don't let anyone shame you for that. Expert or beginner (and yes, act accordingly), you are responsible. You are a leader!

[1] About Agendashift
[2] Scrum and Kanban revisited
[3] Agendashift in 5 principles

I am grateful to Olivier My, Neil Killick, Johan Nordin, And Karen Beck for their valuable feedback on the premise of this article.