Scrum and universal truths

An update to the Scrum Guide will be released on 7 November 2017. In a webinar the principal co-creators of Scrum, Jeff Sutherland and Ken Schwaber, will introduce the changes relative to the previous update. The previous update was released on 6 July 2016 and encompassed the addition of the Scrum Values.

Although language and words matter, I imagine the difficulty of the rewording involved in updating the Scrum Guide. The Scrum Guide holds the single definition of Scrum for countless practitioners across the world, all employing Scrum in unique environments and varying situations. I imagine the discipline of updating the Scrum Guide knowing that many people will not read it. Most of all, I imagine the difficulty of updating the Scrum Guide knowing that many will micro-dissect the texts to identify the tiniest of changes. Many over-think individual words upon the (false!) assumption of traps, tricks and hidden messages. Many still look for methodological exactness and universal precision.

Regardless, the fact that Scrum has a clear and documented definition is priceless. The Scrum Guide provides clarity and purpose, albeit not the perfect precision that many seem to look for.

Scrum is a tool. Useless unless employed. The Scrum Guide intentionally has no universally applicable, detailed instructions or tactics that in the end only work in specific circumstances. The Scrum Guide describes how the tool works, the rules and roles that apply, the behaviors that make the tool work; not the tactics to apply the rules. Scrum, by design, offers room and breathing space, inviting people to conceive an approach specific to their context upon the empirical foundation of Scrum. Scrum is a framework, not a traditional IT methodology. The Scrum Guide describes the framework, the minimal boundaries within which people deal with complex challenges and create complex solutions in complex circumstances.

All exact decisions within those boundaries depend on people, tools, technology, business domain, organizational environment, market situation, and many other aspects.
What is the availability of people? Their skills, experience? How well do teams gel? Do they work remotely, or co-located? How long have they been working together? How much multi-tasking does a team or team members have to do? How well are teams facilitated by the environment? What technology is being used? Which version? What dependencies are at play? What development practices does a team have in place? What tools and infrastructure are at the teams’ disposal? How long are the Sprints? How is the connection with product management? What is the competition doing?

The Scrum Guide does not have the false pretence of offering universal truths, universal answers that apply in every single situation. Scrum essentially invites people to regularly match the actual state of their work against reality, in order to re-align and adapt to new circumstances and incorporate new insights. Scrum is a simple framework for complex product delivery.

The Scrum Guide offers the simplicity needed, without being simplistic about the unique challenges that teams face. I notice how many people struggle with this deliberate imprecision when they try to improve their understanding of Scrum. They look for detailed instructions. They ask universal questions and demand exact and precise answers.
How long should Sprint Planning be? And the other events? How much time does the Product Owner role take? Is the Scrum Master role a full-time job? Should a team be available full-time? How must we organize when the team is distributed? How much time of a Sprint should a team spend on testing? How many business analysts are needed in the team? How should we calculate utilization? How can we measure productivity? Should the Product Owner and the Scrum Master understand the technology? What if… ?

No document, no matter its size, can provide exact answers to these questions for all Scrum practitioners around the globe. It requires courageous professionals (Scrum Masters, trainers, and otherwise) to build on the language and words provided by the Scrum Guide and explain intent and purpose. It requires skilled professionals to help teams, organizations, and students grow an understanding of how Scrum supports them in empirically dealing with the diverse, complex challenges they face in their real-life complexity. Such professionals understand that what works today might not work tomorrow. Exact instructions lead people astray, undermine their ability to think autonomously in terms of Scrum.

My personal stance, as a trainer, a friend, a trusted advisor, a whatever in Scrum, is to facilitate people in understanding the purpose of the rules and the roles of Scrum. I consider it the only viable way for people to devise their own solutions employing Scrum. No external instance, expert or otherwise, can or should do that for them. It may be tempting. It is certainly highly convenient. It might make a person appear knowledgeable. But it promises certainty where there isn’t. That is unprofessional. It ignores context and complexity. It ignores people’s intelligence and creativity.

I am extremely wary of being seen as an ‘expert’ providing universal solutions. Consider me an eternal novice instead.

Every case of Scrum is unique. There is no copy-paste. There are no universal truths in the complex novelty space. The definition of Scrum requires no methodological precision. There is no future in ignoring complexity.

Worrying interpretations of Scrum

At an Agile event I attended recently the speaker surveyed the audience about the 9 elements that form Scrum. My suspicion was immediately raised with mentioning of “9”. It only got worse when the speaker came up with:

Definition of Scrum (9)

It got me wondering how many misconceptions of Scrum can be expressed in no more than two minutes:

Definition of Scrum (9?)

I was hoping that by now (2016), and certainly given the availability of the Scrum Guide (since 2010), the basic understanding of Scrum was better.

What worries me the most however is not the formality of the wrong and missing elements, but how this reflects an ineffective use of the Scrum framework, a limitation to how Scrum supports teams in creating great software products:

  • Accountability over the self-organized creation of Increments belongs to the Development Team as a whole. Synergy is key, not individualism.
  • Transparency is optimized when Product Backlog holds all types of work and requirements for the product. The format and syntax of Product Backlog items is open for the teams to decide over. User Stories are certainly not mandatory.
  • Burn-down charts were removed as mandatory from Scrum some years ago. It was replaced by the expectation that progress, regardless the format, is visualised on Product Backlog and Sprint Backlog.
  • If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a releasable Increment in a Sprint. It is the basis of empiricism, of business agility. Imagine my surprise that this was not even mentioned, THE core purpose of Scrum.
  • Scrum has no prescription that the Daily Scrum needs to happen standing up. Scrum’s interest is making sure that the team’s progress toward the Sprint Goal is inspected on a daily base, in order to allow the team to adapt.
  • The Sprint Review is a collaborative event at which the Scrum Team and the stakeholders work together, and identify what is most important to work on next. Adding input from the stakeholders to the inspected, current state of the software (via the Increment), improves that decision. It is so much richer than a demo.
  • All events in Scrum are contained within a Sprint. Sprints take no more than 30 days, and often less. Not mentioning the Sprint as such (container) event might allow to overlook that aspect.

Definition of Scrum (11)