What Is ScrumBut, and Why Should You Avoid It?

29 June 2022

Veronika Nedashkovskaya

Content Manager

The often-cited Scrum coach Jim York once said, “Scrum is simple. Doing Scrum is hard.” Indeed, The Scrum Guide is easy to grasp. Many businesses, however, don’t follow the framework strictly. While it may seem a logical step in adjusting your workflows, this policy often has dire consequences. 

ScrumBut is one of the most widespread and controversial examples. It resulted from many misconceptions about Scrum and the impact of its adoption. The Rocketech experts have explained ScrumBut, 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.

Graphical user interface

Description automatically generated with low confidence

What Triggers ScrumButs?

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

  • 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.
  • The 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.
  • 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 the 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 authorised 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 rhythm with pauses between Sprints.
  6. There are no Working Agreements.
  1. The team doesn’t use vision and business value techniques (Product discovery, Value Proposition, User Personas, User Story Mapping, etc.).
  2. Product vision, release and Sprint goals are not communicated to all team members.
  3. The team doesn’t adjust iteration targets based on market feedback after launch.
  4. Product Backlog does not reflect on the element value.
  5. The Definition of Done is not defined or communicated to the team members.
  6. Testing is not included in development Sprints and is not automated.
  7. Product Owner manages Scrum Master.
  8. Product Owner doesn’t know the product’s target audience.
  9. Product Owner doesn’t provide the team with constructive feedback.
  10. There are different Scrum Masters in every Sprint.
  11. One team member functions as both Product Owner and Scrum Master.
  12. The development team is divided into sub-teams.
  13. The team members are involved in multiple projects simultaneously.
  14. A Daily Scrum takes much longer than 15 minutes.
  15. The team works on the backlog arbitrarily and doesn’t consider the Product Owner’s priorities.
  16. There are no metrics and assessment methods.
  17. The Sprint Retrospective turns into finger-pointing.
  18. There’s a lack of task planning before the Sprint.
  19. 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 the 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”.

Diagram

Description automatically generated

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.

At Rocketech, we believe that Scrum is the best fit for startups. It helps founders analyse the 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. Contact us for more details.

Get a bi-weekly email with the most popular stories

Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.

Tell us what you have in mind

If you'd like to get in touch with us you can email us at info@rocketech.it, call us on +65 3159 3765, send us a message via our online form, or get answers in real time by simple briefing @RocketechHelloBot.
SingaporeKyivLondonSan Francisco