Truth, Lies, and Scrum

I enjoy when people contribute their knowledge about agile software development to other humans living on planet Earth. The wisdom I’ve gained from such mentors aside, I think it’s terrific people are passionate, engaged, and excited enough to share their insights with others. As the most popular way to put agile values and principles in play, Scrum is arguably the subject most frequently written about in the agile community. Again, these articles and discussions about Scrum (and inferences about agile) are intended to assist, educate, and inform others in improving their careers and/or perspectives. This is terrific, too. Unfortunately, much of what is written tends to be misguided, misunderstood, or flat-out wrong. 

With respect and kindness for all those who take time to contribute, especially those cited as examples of problems, I’d like to share some truths of what Scrum is, what it isn’t, and how you can improve as a practitioner. This isn’t an all-inclusive list; just a handful of topics which I see misrepresented often. 

Scrum != Agile

Often, folks directly or indirectly infer Scrum is synonymous with agile. For example, “the agile scrum methodology” or Capital One’s use of Scrum Masters “as originally described in the agile manifesto.”

Agile is a set of four values and twelve principles describing behaviors and relationships between people (see: the agile manifesto). Scrum adopts the values and principles of the agile manifesto to create a framework for delivering products which benefit from rapid, closed feedback loops. Therefore Scrum is an agile “process” where the entire spectrum of discovery to delivery to maintenance is possible.

Scrum itself is not agile, nor is Scrum another way to refer to agile. A relationship I learned from my friend, Tim Ottinger, to assist people with better understanding is: “Scrum is to agile as beagle is to dog.”

Your context and culture dictates Scrum’s effectiveness.

I’m aware of illustrations and diagrams floating around which suggest things like “complicated work” is best for agile, where “complex work” is the sweet spot for Scrum, saving “chaotic work” for Kanban (and other confusing statements).

When work gets “complex”–which probably has a different interpretation from one person to another–Scrum is not necessarily better for the job. Scrum is a delivery framework powered by frequent closed feedback loops across the big picture – from within your codebase, within your team(s), within your organizational system(s), to your customers themselves. If your product(s) would benefit from relationships built upon collaboration, frequent communication, and feedback on your product(s), Scrum might work well for you… regardless of whether you want to categorize something as “complex”, “chaotic”, or “utter and total unmitigated madness.”

Your organization will likely need a new structure to use Scrum.

The easiest part of work to see are the processes, activities, and artifacts of people’s work. Therefore, it’s unsurprising the aspects of Scrum which receive the most attention (e.g., training and certification) are the ceremonies, roles, and other process elements of Scrum. Putting it all together, it shouldn’t surprise you most (all?) organizations using Scrum treat it as a replacement for their old processes (leaving the existing structures, such as divisions of labor, management, and rewards, intact).

Given Scrum is informed by agile values and principles, which are inherently invisible, it’s easy to miss the fact Scrum probably doesn’t align well with your existing organizational design. Was your company designed to work according to the Scrum framework or adapted over time to discover it? Unlikely.

Overlaying Scrum process on top of existing structure will unsurprisingly result in TACO Scrum: Titles and Ceremonies Only. If organizational transformation were about changing process, there would be success stories everywhere. Protip: there aren’t.

The Scrum Guide is not a straw-man document.

Scrum is literally defined by the Scrum Guide. Within its neatly organized sections contains the definition of what Scrum is, how it works, what behaviors people adopt, and other supporting info. It is not a set of guiding boundaries or suggestions. It is the literal, absolute definition of what Scrum is.

If one were to take the contents of the Scrum guide and use it as a lens to view the organization, should the definitions and outcomes of the guide be missing or incomplete, the organization is not using Scrum.

One could call it Scrum (as many do) or proclaim, “no one does Scrum by the book anyway!” The fact of the matter remains, if you’re following the Scrum Guide you are using Scrum. If not, it’s not Scrum. Period.

Daily Scrum is a feedback loop.

A short, daily gathering of the team to set a plan for the day originates from XP. In Scrum, the event is called, “Daily Scrum”. In application and intent, the two are quite similar. However, per the Scrum framework, the Daily Scrum is an activity for Scrum teams.

The Scrum Guide is continuously evolving based on feedback and learning. In 2017, the definition of Scrum was changed to describe “the three questions” as a way the team might discuss their plan for the day. Prior to this change, “the three questions” were described in a way which could be interpreted as a requirement. In other words, “everyone answers the same three questions” used to be frequently interpreted as canon.

Therefore, it is unsurprising when I observe teams mechanically, and with much monotony, proceed in clockwise progression around the room individually answering the same questions.

However, as the Scrum Guide today highlights, the intent of Daily Scrum is establishing shared understanding amongst the team of the feedback loop they intend to inspect the next day. A Scrum team might answer three questions each, but only because the team understands the intent and has selected the three questions as the best means to accomplish their goal.

Should you hear, “Katie, what’s your update?” be curious indeed. In Scrum, teams work together daily and agree together on how best to do that, using the Daily Scrum as advancement for their learning.

Scrum Master is not a role “in agile.”

Scrum Master is a required role in Scrum. There is no establishment of a Scrum Master, Agile Coach, Delivery Lead, Agile Consultant, Agile Manager, Team Coach, Certified Certifier, or other title in the agile manifesto. The manifesto is mute (agnostic) on these matters.

Agile teams do not have Scrum Masters. Scrum Teams have Scrum Masters.

Scrum Masters are not a sign or assessment of “maturity”.

The role of Scrum Master is to catalyze improvement, knowledge creation, a positive work environment, a safe place to contribute, new insights, creativity, risk taking, a focus on customer and delivery, facilitation of continuous improvement, feedback loops, and mentor everyone on Scrum.

Systems thinking teaches us the cause-effect relationships within the system create ever changing, ever moving leverage and outcomes. Jerry Weinberg made this principle easy to comprehend with “Rudy’s Rutabaga Rule”.

Therefore, if your Scrum Masters are not focusing on the behaviors described above, emphasizing instead things like assignment, tracking, reporting, scheduling, governance, managing, and policing, you don’t have Scrum Masters.

If your Scrum Masters aren’t focusing on the behaviors above because they are not allowed, YOU are not doing Scrum.

User stories are not part of Scrum.

The “Connextra Template”, aka user story, was created by a team working at Connextra in the UK. Rachel Davis is most frequently attributed as the primary author of the template, although many people have contributed to its advancement.

User stories are not a part of Scrum. Therefore, “proper formatting” of a user story is not a part of Scrum. Product Owners do not need to write user stories. Scrum teams do not need to use stories.

In fact, there is no prescription for the backlog in Scrum. Instead, Scrum requires a team’s understanding of value, agreement on what criteria to inspect (with customers and stakeholders) for checking this understanding of value, and acceptance of how to work together (e.g., any decomposition desired to achieve the feedback loops expressed above).

Scrum does not require you to make everything “a story”.

The outcome of the Sprint Review is an updated product backlog.

It’s right there in the Scrum Guide: “The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.” Of course, it’s still possible nothing changes with respect to opportunities and priorities. Regardless, the intent is clear: the sprint review is the most important success feedback loop in Scrum.

This has a very powerful effect in describing the intent of the sprint timebox:

A sprint without an impact on the product backlog, priorities, understanding of value, customer relationship, or other feedback loops related to adapting how next to proceed is not Scrum.

When a team is engaged with “breaking” or “slicing” work to fit in the timebox, the conversation is really about maximizing value and amplifying the sprint review feedback loop. Thus, if you’re breaking down work just to complete a sprint forecast, you’re not doing Scrum.

Velocity is not part of Scrum.

The word “velocity” appears exactly zero times in the Scrum Guide. Therefore, velocity is not part of Scrum. In fact, velocity finds its origins in XP.

Of course, this doesn’t mean if you’re using “velocity” you’re not doing Scrum. However, I suspect the probability of “not Scrum” increases the more velocity is used or emphasized.

Further, advocating for things like, “as the team gets better, velocity will increase” is utter nonsense. Something like, “as people begin to discover how easily it can be gamed, velocity will increase” is more agreeable.

If retrospectives have no organizational impact, you’re not doing Scrum.

As stated prior, it’s no secret the vast majority of software organizations in the world today were not designed with Scrum in mind. Therefore, using the framework is highly likely to collide with existing structures, rewards, budgets, processes, and management beliefs in a conflicting way. Further, in organizational systems, the cause-effect relationships between parts are pretty dynamic: what teams do affects management, customers, products, other teams, you get the picture.

Therefore, if teams are identifying things which make the team and/or organizational less effective than it could be, yet such things are not evolving to reduce the negative impact (or improve relationships), you’re not doing Scrum, period.

It’s actually quite easy to assess! Where Scrum without agile values and principles is inept and futile, Scrum without empiricism is just as feeble.

Of course, if you’re not finding anything meaningful for improvement in the first place (or dictating what teams should be improving), it doesn’t matter if you’re doing Scrum or not… Scrum won’t help anyway.

Teams are the heart of Scrum, but a bunch of people with the same boss are not necessarily a team.

Who can assign work to a team member? Who gets to tell the team how to do the work? Who controls the team’s time and utilization?

Forming a team is not as simple as grouping folks under an organization’s reporting hierarchy, then applying the title of “Team”. At a minimum, for Scrum teams to be successful, care and attention must be given to three essential base conditions (adapted from Katzenbach & Smith):

• A challenge which requires people to work together for success (as opposed to a challenge where people can work individually, then “sum up” their efforts).
• Mutual accountability among team members.
• A vision shared by team members for culture, how to work together, etc.

I’ll add a fourth here, which might be the most important: trust in the team to self-organize.

Arguably, this is where Scrum falls apart the fastest. The Scrum Guide does a wonderful job of describing the characteristics of a real team, though allowing this team-centric environment to exist is often unfathomable to people.

Suffice to say, you may accept and adopt all of the prior discussions about Scrum, but without trust and real teams, none of it matters anyway.