top of page
Writer's pictureMary Iqbal

Why you shouldn’t modify Scrum

Updated: Nov 7, 2022

Scrum is a framework, not a set of work instructions. There aren't endless pages of process flow diagrams, no detailed agenda for each event, or guidelines for how many Product Backlog items you need and how you should write them.


Instead, the Scrum Framework is very lightweight, and it seems to get less restrictive with each release of the Scrum Guide. What is included is really important, though. Every piece of the framework is there for a reason. In this article, I will discuss five common ways that teams modify the Scrum framework and the negative impacts of each.


Not Delivering value incrementally

In my experience, the most frequently missed element of Scrum is the concept of incremental delivery. According to the 2020 Scrum Guide, “Scrum employs an iterative, incremental approach to optimize predictability and to control risk.” According to Scrum, each Scrum Team - or set of Scrum Teams working on a single product should deliver a usable increment each Sprint. Usable — meaning if the product involves software delivery, it should work at the end of each Sprint.


Teams overlook this element of Scrum — a lot.


Imagine a team building an online car insurance application involving 5,000 fields. The approach to this work should look quite different depending on whether a team is using a traditional waterfall or agile approach. The waterfall team might first build the database with all 5,000 fields. Then, they might create the data interface. Finally, they would deliver the front-end user experience. If there are technical issues, such as the database not working well with the front-end software, they might not discover that until the end of the project because there is low visibility into the progress of the work along the way.


A Scrum Team building this application should deliver a working product with each Sprint. For example, they might build a database, data interface and user experience for the first four fields in one Sprint. In the next Sprint, they might deliver a working application with the following four fields. Each time they complete a Sprint, what they deliver should be usable (Done), even if it is not all 5,000 fields. This approach allows Scrum Teams to discover any technical issues early. They also get stakeholder feedback at each Sprint Review and develop ways to improve their processes at the Sprint Retrospective.


Agile teams use incremental delivery to deliver value sooner by changing the way that we approach our work.

But this is not what always happens. Instead, many supposedly “agile” teams approach the work the same way as a team using a waterfall approach. Instead of delivering a working product incrementally, they fall into the trap of trying to build the database for all 5,000 fields, the data interface for all 5000 fields, and the front end for all 5000 fields. What happens then, of course, is that it takes several sprints to get to Done.


This team might use all five Scrum elements. They may have all three accountabilities. But, they are not fully embracing the Scrum framework because they are not delivering a usable increment each Sprint.


The result of not delivering value incrementally

Teams who ignore incremental delivery don’t get the full benefits of Scrum. They are hampered by lower work visibility, are less able to change direction, deliver business value slower, and cannot reduce risk as early as teams who fully embrace incremental delivery.

Agile teams who use incremental delivery have increased visibility for their stakeholders, maintain a higher ability to change direction, deliver business value sooner and reduce risk faster.  Wow!

Adopting Scrum involves a mindset shift — requiring us to work and think differently. Rather than looking just at the end delivery, teams should sort out the most valuable thing to do next and do it.


Skipping the Sprint Retrospective

Another way teams sometimes modify Scrum is to skip the Retrospective. When they are under pressure to deliver work, some teams see skipping the Retrospective as a way to “save time.” This one really breaks my heart because the Retrospective is a valuable opportunity for the team to inspect themselves and improve how they work together as a team.

So many teams skip the Retrospective in a misguided event to save time, but end up losing time in the long run.

The result of skipping the Retrospective

It’s not much of an exaggeration to say that the result of skipping the Retrospective is catastrophic. Teams that use the Retrospective to make small improvements in how they work together will not recognize themselves in six months. A series of minor improvements makes a bigger impact than any massive one-time re-write of the process could be. Small improvements are less disruptive than large improvements and allow the team to reflect frequently on what is not working and what is working. Teams who do not take these small improvements tend to be lower-performing teams and do not deliver value as quickly to the organization.


Eliminating the Scrum Master accountability

Organizations attempting to save money sometimes eliminate the Scrum Master accountability to reduce the headcount.


Eliminating the Scrum Master accountability causes teams to no longer receive the maximum value from the Scrum framework.

The result of eliminating the Scrum Master accountability

The irony here is that the Scrum Master’s purpose is to improve the adoption of Scrum, resulting in earlier value delivery and more efficient teams. If there is no Scrum Master, the team will likely be lower performing, which delays value delivery resulting in higher costs to the organization. Teams who eliminate the Scrum Master accountability in the hopes of saving money actually lose money in the long run.


No Product Goal

Many Scrum teams do not realize that the Product Backlog should contain a Product Goal. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next. An example of a product goal for a web application might be to decrease shopping cart abandonment or increase sales.

Scrum Teams need a clear Product Goal to ensure that they are headed in the right direction and to give focus to the Scrum team.

The result of not having a Product Goal

Teams without a Product Goal have reduced focus and opaque measures of progress. They are like a ship without a rudder — they may go somewhere, but is it the right somewhere? Who knows? Without a Product Goal, it is hard to evaluate whether the product is heading in the right direction or whether the ordering of the Product Backlog makes sense. In addition, the Product Goal provides transparency to the team and its stakeholders. Without a Product Goal, it is harder to understand the product strategy, resulting in a loss of transparency for the organization.


No Definition of Done

A Definition of Done (DoD) describes all the work the team needs to complete for each Product Backlog item before considering it Done. As the 2020 Scrum Guide poetically puts it, “The moment a Product Backlog item meets the Definition of Done, an Increment is born.”

A clear Definition of Done provides transparency and helps Scrum team plan the Sprint effectively.

Imagine that your Scrum Team is baking a batch of cookies this Sprint. Each team member might have a different idea of when the cookies are “Done.” For some, it is when the cookies come out of the oven, while others believe it’s when they are on the cooling rack. Still others might consider the cookies done after they put them away and clean the kitchen. A DoD offers the Scrum Team a guide for how much work they need to do before considering each Product Backlog item Done. This information provides the Developers with critical guidance for how many Product Backlog items they can pull into the Sprint.


A Definition of Done provides transparency to all stakeholders, clarifying what it means when a Developer says that a Product Backlog item is Done. Does it mean the item has just been tested or tested and integrated into the main code base? The DoD makes it clear.


The result of not having a Definition of Done

Without a common understanding of all of the work that needs to be completed for each Product Backlog item for it to be Done, it’s unclear how many items the team can pull into the Sprint. Pulling in too many items will risk meeting the Sprint Goal.


An unclear DoD will also mean the Scrum Team and its stakeholders will not have transparency regarding the Increment delivered. For example, the Product Owner might not know the level of performance testing happening. For a software product, this might mean that some Developers are conducting code reviews and some or not. Or, some Product Backlog items might be development-only stories, and some are testing-only stories. Perhaps Product Backlog items are not yet integrated into the main code base. This lack of transparency around the Increment reduces the team's adoption of empiricism. Scrum’s foundation is the empirical control process. The framework performs best when events, artifacts and accountabilities of Scrum embody the three pillars of transparency, inspection, and adaptation. (See our recent article Is your Team “Pretending” to be Agile? for a fuller discussion of Empiricism.)

The three pillars of Empiricism are Transparency, Inspection and Adaptation.


Conclusion

Adopting the Scrum framework is the first step towards a better way of delivering complex products. It can be tempting for those newer to Scrum to think that modifying some Scrum elements will make it easier to adopt, but it’s the opposite. When teams modify the Scrum framework, they are not experiencing its full benefits, likely resulting in lower-performing teams and slower value delivery to the organization.


New to Scrum? I recommend the Applying Professional Scrum (APS) course. APS allows those new to the framework to understand the Scrum roles, artifacts and events. Both public and private classes are available. Contact Rebel Scrum to learn more.