Table of Contents
- Why Sticking to the Scrum Guide Matters: Preserving Scrum Purpose and Avoiding the Pitfalls of Terminology and Framework Changes
- The Danger of Changing Scrum: Insights from the Scrum Guide
- Why I Never Recommend Altering Scrum Terminology or Design
- The Bigger Issue: Altering Scrum Framework Principles
- Employing Ideas To Scrum Without Breaking It
Why Sticking to the Scrum Guide Matters: Preserving Scrum Purpose and Avoiding the Pitfalls of Terminology and Framework Changes
The Danger of Changing Scrum: Insights from the Scrum Guide
To truly understand Scrum, it’s essential to grasp its core purpose. The Scrum Guide 2020 emphasizes that modifying Scrum’s design and principles undermines its purpose.
So, why is this important? Scrum is a framework built on tried-and-tested principles, designed to enhance team collaboration and deliver value incrementally. Altering its structure risks introducing inefficiencies, losing transparency, and, ultimately, undermining your team’s productivity. If we’re not following the framework as intended, we’re not truly practicing Scrum.
Scrum Purpose
Watch the Video for a Complete Overview!
Why I Never Recommend Altering Scrum Terminology or Design
From my perspective, changing Scrum terminology or its design is a risky path to take. Yet, it’s unfortunate to see many teams not only making these changes but also spreading misleading interpretations. One particularly common example is transforming Scrum Events into “ceremonies” or “rituals.”
Let’s take a closer look. In Scrum, events—such as the Daily Scrum, Sprint Planning, and Sprint Review—are structured moments of collaboration designed to drive progress and maintain transparency. But in some organizations, these events are referred to as “ceremonies,” giving them an air of grandeur that feels out of place.
Consider this example of how Rocky handles the Daily Scrum Event:
See how simple that was? This is the essence of the Daily Scrum: a quick, focused event to align the team. Notice that Rocky was even sitting during this exchange—there was no need to call it a “StandUp.” The term “Daily Scrum” is deliberate and functional, whereas calling it a “ceremony” makes it sound unnecessarily elaborate, like a wedding or an awards show.
Here’s how it might sound if it truly were a ceremony:
Now, doesn’t that feel absurd? The term “ceremony” can create an impression that Scrum Events are overly formal or theatrical, which distracts from their true Scrum purpose: fostering transparency, inspection, and adaptation.
And let’s not even start on calling these events “rituals.” That just takes things to an entirely new level of intensity. Imagine this:
Does that sound productive to you? Of course not. The exaggeration here highlights how far removed these terms are from the practical, no-nonsense philosophy of Scrum.
The Bigger Issue: Altering Scrum Framework Principles
While terminology changes may seem minor, the real problems arise when organizations start modifying the fundamental ideas and principles of Scrum. Here are just a few examples of how these changes can undermine the framework:
Ignoring timeboxes: Scrum Events are timeboxed to maintain focus and efficiency. Removing or extending these limits can lead to wasted time and reduced productivity.
Maintaining multiple Product Backlogs for a single product: This disrupts the team’s alignment and creates confusion about priorities.
Lack of transparency in the Definition of Done: Without a clear and agreed-upon Definition of Done, teams risk delivering incomplete or low-quality work.
Product Owner leading the Daily Scrum: This breaks the self-organizing nature of Scrum teams, shifting responsibility away from the team.
Disrespect among team members: Scrum is built on collaboration, trust, and mutual respect. Failing to uphold these values can destroy team morale and cohesion.
These issues are far more than simple terminology debates; they represent a departure from what makes Scrum effective. When the framework is not followed as intended, the Scrum purpose—enhanced collaboration, improved transparency, and faster delivery of value—is compromised.
Employing Ideas To Scrum Without Breaking It
Okay, now that we understand the Scrum Guide doesn’t support changes to its core ideas and design, let’s explore how we should adhere to the guide.
The key thing to understand here is that while changes and modifications are not supported, it doesn’t mean that other techniques, processes, or methods aren’t welcome! Yes, you shouldn’t attempt to change the core design of Scrum, but as long as you aren’t undermining it, you can and should use other techniques or methods. Actually, it’s not just that you might use them—you need to. In our previous video, we discussed Scrum as a framework and highlighted that Scrum is deliberately incomplete, focusing mainly on WHATs! However, figuring out HOW to implement Scrum is a challenge for you as a Scrum Master, and you may need to employ various practices and methods for that.
Employing Ideas From Scrum
Let’s distinguish between employing ideas from Scrum and employing ideas to Scrum. When you employ ideas from Scrum, it’s like borrowing. For example, you might like the idea of Daily Scrum but decide not to hold Sprint Retrospectives or other events described in the Scrum Guide. In this case, you’re borrowing just the idea of the Daily Scrum. But can you say that running a Daily Scrum makes your company fully Scrum-compliant? No, right?
Here’s an analogy: I have a cake with strawberries and cream on it. If I eat only the strawberries and cream, have I eaten the whole cake?
The problem arises when there’s a lack of understanding behind events, artifacts, accountabilities, and rules of Scrum. This can lead to minimal change, with teams not experiencing the full benefits of Scrum. Simply saying, “Our organization follows the Scrum framework” would then be misleading. Don’t get me wrong—borrowing ideas is okay! Not following the Scrum framework is okay too! Discovering that Scrum isn’t the best fit for your organization or team is also okay! But borrowing some ideas from Scrum and partially implementing them is not okay because it simply isn’t Scrum anymore!
Employing Ideas To Scrum
Now, when we talk about employing ideas to Scrum, consider practices like Planning Poker, User Stories, Code Refactoring, Test-Driven Development, Sprint 0, or Integration Sprints. These aren’t explicitly mentioned in the Scrum Guide, but their absence doesn’t mean they aren’t welcomed.
Take User Stories, for example—they’re features written from the end-user perspective, focusing on adaptability and change. They emphasize delivering value and continual improvement. Planning Poker, a technique for estimating User Stories, fosters transparency and collaboration. It complements Scrum principles without contradicting them. Similarly, practices like code refactoring or test-driven development aren’t detailed in the Scrum Guide, yet principles like lean thinking, waste reduction, complexity reduction, and quality improvement align with these practices. They support, rather than undermine, Scrum principles.
Now, what about concepts like Sprint Zero, Integration Sprints, or Hardening Sprints? Let’s quickly define them. Sprint Zero typically focuses on creating a product backlog, establishing workflow strategies such as coding standards, and defining documentation. An Integration Sprint dedicates time to combining features into a cohesive whole. And a Hardening Sprint, often seen as bug-fixing sprints, addresses technical debt.
However, each has its challenges. Just one problem can be enough to discredit these concepts. For example:
- Sprint Zero: What’s the deliverable here? How can we ensure it provides a valuable and useful Increment? Are we trying to create a perfect plan for product development?
- Integration Sprint: Do we truly need it? If we’re at the point of needing an Integration Sprint, it might indicate earlier missteps.
- Hardening Sprint: This can lead to a focus on delivering something rather than delivering value. In some cases, meeting deadlines results in releasing unfinished work, creating technical debts and necessitating additional hardening sprints.
Real-World Examples: How Deviating from Scrum Purpose Puts Your Team at Risk
Alright, finally, let’s explore why the Scrum Guide emphasizes that altering its core design could diminish its benefits. I began this discussion by searching for the elusive Scrum book that some people reference when they say, Stop following Scrum by the book! Spoiler alert: I didn’t find such a book. Yes, there are numerous books on Scrum—I’m currently reading works by Ken Schwaber, one of Scrum’s co-creators. Coming from a game development background, I also recommend Clinton Keith’s book, which offers great insights into using Scrum in game development.
But here’s the thing: while these books are excellent resources full of stories and case studies, they are not definitive guides. Scrum is applied across various fields, so adhering blindly to specific implementations from these books often isn’t feasible. The only definitive source you can rely on is the 13-page Scrum Guide, which is intentionally abstract, straightforward, and incomplete by design.
So, interpreting following Scrum by the book as adhering to the Scrum Guide is crucial. When people suggest not implementing Scrum by the book, it could be extremely risky because, as the Scrum Guide states, deviations from its principles often mask underlying issues. Let’s unpack some common scenarios:
Scenario 1: Management Cancels a Sprint
Imagine management decides to cancel the current Sprint due to sudden stakeholder demands. You might point out that, according to the Scrum Guide, only the Product Owner has the authority to cancel a Sprint. However, the response is often, “Let’s not follow Scrum by the book.” Why? Because the “why” behind the process isn’t clear.
The root issue could be a lack of transparency between the Scrum Team and stakeholders, leading to last-minute surprises. Alternatively, the Product Owner may not have prioritized backlog items effectively. As a Scrum Master, you’d need to address these transparency issues, inspect how Sprint Reviews are conducted, and organize meetings to improve collaboration between stakeholders and the team.
In such cases, redefining the Product Goal, refining the backlog, and educating stakeholders on the implications of canceling Sprints are critical steps. This also highlights the importance of discussing these issues during the Sprint Retrospective and accommodating them in the next Sprint Planning.
Take the First Step with Art's Scrum Services
Scenario 2: Extending Sprint Planning or Introducing "Hardening Sprints"
Now consider a situation where management wants to extend Sprint Planning to two days: one day for lead discussions and a second day for informing the team of new goals, with a “Hardening Sprint” sandwiched in between. This proposal completely disregards Scrum principles.
First, having separate lead meetings introduces a hierarchical approach that undermines collaboration and transparency. This creates uncertainty among team members and wastes time. Second, asking the team to work on bugs during Sprint Planning is counterproductive. Lastly, the notion of a “Hardening Sprint”—a separate phase to finalize or polish work—contradicts Scrum’s iterative and incremental nature.
The entire Scrum Team must define the Sprint Goal together. Scrum Developers should actively participate in Sprint Planning—not just be informed about the goal afterward. After all, they’re the ones creating the sprint backlog and running the Daily Scrum. It’s not about being told, “Now do this!” but collectively deciding, “Here’s what we’re going to accomplish next!”
Staying True to Scrum Purpose for Long-Term Success
To summarize, it’s crucial to understand that modifying the core ideas of the Scrum Guide and claiming it’s still Scrum undermines its true Scrum purpose. However, adopting new techniques, processes, or tools that align with Scrum’s core principles is always encouraged. Following Scrum by the book—by the Scrum Guide—isn’t about being rigid; it’s about staying true to its foundational values and ensuring that you address problems instead of covering them up.