What Is ScrumBut, and Why Should You Avoid It?

Jim York, the often-cited guru of Scrum, an agile methodology for managing and completing complex projects, once said, “Scrum is simple. Doing Scrum is hard.” Indeed, The Scrum Guide is easy to grasp. However, many businesses don’t follow the framework strictly. Although implementing the framework might appear a reasonable action to adjust workflows, it frequently leads to serious and negative outcomes.

ScrumBut is one of the most widespread and controversial examples. It resulted from many misconceptions about Scrum and the impact of its adoption. Stemming from a misinterpretation or selective adoption of Scrum principles, ScrumBut represents a diluted version that undermines the intended benefits. We explained the phenomenon, its meaning, and why you should avoid it.

ScrumBut Definition

According to Scrum.org, “ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team”.

To simplify this, a ScrumBut has a specific syntax:

(ScrumBut)(Reason)(Workaround).

Here are some real-life ScrumBut examples.

• (We use Scrum, but) (having a Daily Scrum is too expensive,) (so we only have it once a week.)
• (We use Scrum, but) (Retrospectives are a waste of time,) (so we skip them.)
• (We use Scrum, but) (we can’t create the functionality within a month) (so our Sprints last six weeks.)
• (We use Scrum, but) (sometimes our managers give us special tasks,) (so we don’t always have time to match our Definition of Done.)

In a broader sense, ScrumBut is a methodology one can call a restricted Scrum. It’s the framework’s deviation that implies that the team only uses parts of it while leaving aside other elements (the ones you think you don’t need). However, to see what you need and what you don’t, you must understand the principles of classic Scrum. And that’s where troubles begin.

What Triggers ScrumButs?

While ScrumButs are reasons themselves, they also have the rationale behind them.

#1 Misinterpretation of The Scrum Guide

Remember, Scrum is compact and easy to understand but difficult to master. Although the elements are described straightforwardly, many companies misread the guide or (often) skip its parts, which leads to framework dysfunctions.

#2 Inappropriate Context for Scrum

It’s a framework designed to develop, deliver and support complex products. Sometimes it’s simply not suitable for solving your problems. You may not need all Scrum Ceremonies to redesign a few pages of your corporate website.

#3 Conscious Simplification of the Rules

Some executives ignore parts of the Scrum process or consider them secondary. Meanwhile, all Scrum roles, events, and artifacts are closely linked and aimed at achieving the common goal — to provide customers with a product of maximum value.

What Hinders Scrum Adoption?

About a decade ago, the Internet was somewhat positive towards ScrumBut practices. Nonetheless, Ken Schwaber, one of the leaders of the agile software development movement first used the term “ScrumBut” to describe a misinterpretation or a deliberate modification of the rules of Scrum to escape from the painful truth about the process it helps discover.

Certainly, some deviations are common in the early stages of the agile methodology adoption. They are part of the process evolution. For example, if you use Scrum but don’t practice TDD (test-driven development), pair programming, or collective code ownership, maybe you’re just at the beginning of the agile journey. It takes time.

However, “we use Scrum, but” in mature teams should raise questions about the actual causes that drive this modification. And often, there are a few valid reasons. Rather, it’s a misunderstanding of the agile process values or a lack of the courage and consistency to follow them.

25 Common Mistakes Disrupting the Scrum Process

Depending on the project’s context, some points may have varying impacts. But every element of this list leads to a distortion of agile and Scrum values and principles.

1. The team is not authorized to change the development process.
2. There is no list of problems and a systematic working process to resolve them.
3. There is no investment (time, money) to work on problems.
4. The Sprint length increases on the go or changes frequently.
5. Developers have inconsistent development rhythms with pauses between Sprints.
6. There are no Working Agreements.
7. The team doesn’t use vision and business value techniques (Product discovery, Value Proposition, User Personas, User Story Mapping, etc.).
8. Product vision, release, and Sprint goals are not communicated to all team members.
9. The team doesn’t adjust iteration targets based on market feedback after launch.
10. Product Backlog does not reflect on the element value.
11. The Definition of Done is not defined or communicated to the team members.
12. Testing is not included in development Sprints and is not automated.
13. The Product Owner manages Scrum Master.
14. The Product Owner doesn’t know the product’s target audience.
15. The Product Owner doesn’t provide the team with constructive feedback.
16. There are different Scrum Masters in every Sprint.
17. One team member functions as both Product Owner and Scrum Master.
18. The development team is divided into sub-teams.
19. The team members are involved in multiple projects simultaneously.
20. A Daily Scrum takes much longer than 15 minutes.
21. The team works on the backlog arbitrarily and doesn’t consider the Product Owner’s priorities.
22. There are no metrics or assessment methods.
23. The Sprint Retrospective turns into finger-pointing.
24. There’s a lack of task planning before the Sprint.
25. There are additional roles like release managers or development managers responsible for parts of the project’s success.

And this list can be endless. The researchers from Tampere University and the University of Helsinki conducted an empirical study on the cases of Scrum deviations in real-life conditions. The paper concludes that while some of them are “seemingly attractive”, they “may nevertheless have unpleasant consequences”.

Source

Why ScrumBut Is Ineffective

ScrumBut is essentially using only a fraction of the Scrum principles. However, you can only leverage all advantages of Scrum software development methodology if you follow the framework strictly. Many founders think skipping one or two Daily Sprints won’t affect the overall process. In reality, even the slightest deviation makes it “non-Scrum”. The official Scrum guide says: “While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety”.

Many founders try to invent their own approaches and methods while adopting the classic textbook Scrum can help them reach the desired results faster and more effectively. Scrum is more than just managing a development team. It’s about the functional business and resource planning that helps you create products that customers need. And no strategy can guarantee the outcome if not followed entirely.

You can only leverage all advantages of Scrum software development methodology if you follow the framework strictly.

At Rocketech, we believe that Scrum is the best fit for startups. It helps founders analyze team efficiency and adjust flexible release planning, which is essential in highly competitive markets with ever-changing demands. After 150+ successful projects, we see Scrum as a mindset and apply its best practices accordingly. And we are happy to share our expertise.