"We're doing Scrum, but..."

If you've ever heard this phrase in your organization—or worse, caught yourself saying it—you've encountered ScrumBut. It's the most common indicator that your team isn't actually doing Scrum. You're doing something else entirely.

And here's the problem: that "something else" usually gives you all the overhead of Scrum with none of the benefits.

What Exactly is ScrumBut?

ScrumBut is a term coined by Ken Schwaber and Jeff Sutherland (the co-creators of Scrum) to describe teams that claim to practice Scrum while systematically skipping or modifying key elements of the framework.

The pattern is always the same:

The "but" is where agility goes to die.

The Hall of Shame: Most Common ScrumButs

Let's look at the classics. You've probably heard—or said—at least one of these:

• "We're doing Scrum, but we don't do retrospectives." Translation: "We repeat the same mistakes every sprint and wonder why nothing improves."
• "We're doing Scrum, but our sprints are six weeks long." That's not a sprint. That's a mini-waterfall with daily standups.
• "We're doing Scrum, but we add work to the sprint whenever it comes up." So you have no sprint goal, no commitment, and no ability to plan. Got it.
• "We're doing Scrum, but the Product Owner is too busy to attend sprint planning." Then you don't have a Product Owner. You have someone with a fancy title who isn't doing the job.
• "We're doing Scrum, but we skip daily standups when we're busy." You mean when you need coordination the most? Brilliant.
• "We're doing Scrum, but we don't have a Scrum Master." Because who needs someone focused on improving how the team works, right?

Why Teams Fall Into the ScrumBut Trap

Here's the thing: teams don't adopt ScrumBut because they're lazy or incompetent. They do it because they're under pressure and something has to give.

The typical story goes like this:

Management mandates "agile." The team starts with genuine Scrum. Everything feels like extra work at first—ceremonies eat up time, the Product Owner role is awkward, the Definition of Done seems restrictive.

Then pressure hits. A deadline looms. A key stakeholder demands a feature mid-sprint. The team is "too busy" for that retrospective.

One compromise leads to another. Before long, you're not doing Scrum anymore. You're doing ScrumBut.

The cruel irony? The shortcuts taken to save time usually create more problems than they solve. You end up spending more time firefighting than you would have spent doing Scrum properly.

The Real Cost of ScrumBut

ScrumBut isn't just about violated principles or purist complaints. It has real, measurable consequences:

You lose predictability. Without consistent sprint lengths and protected sprint scope, you can't forecast. Your velocity data becomes meaningless. Stakeholders never know when things will actually ship.

You lose transparency. When you skip retrospectives or daily standups, problems stay hidden. Technical debt accumulates. Team dysfunction festers. By the time issues surface, they're crises.

You lose the feedback loops. Scrum's ceremonies exist to create rapid feedback. Skip them, and you're flying blind. You find out six weeks later that you built the wrong thing.

You lose team morale. Nothing kills motivation faster than fake agile. The team knows they're not really doing Scrum. They see the dysfunction. But they're told to keep pretending everything is "agile."

How to Spot ScrumBut in Your Organization

Not sure if you're guilty? Ask yourself these questions:

• Can anyone outside the team add work to your current sprint without consequence?
• Are your sprints longer than four weeks—or do they vary in length?
• Do you regularly skip any Scrum ceremonies?
• Is your Product Owner unavailable for sprint planning or backlog refinement?
• Do you go more than three months without adjusting how you work based on retrospective insights?
• Can you articulate your current sprint goal without checking documentation?
• Does your team have a clear, enforced Definition of Done?

If you answered "yes" to the first five questions or "no" to the last two, you've got ScrumBut.

Breaking Free: From ScrumBut to Actual Scrum

The good news? You can fix this. But it requires honesty and commitment.

Step 1: Admit the problem. Stop saying you're doing Scrum when you're not. Call it what it is—ScrumBut, hybrid agile, or just "our process." Honesty is the first step to improvement.

Step 2: Understand why Scrum works. Each ceremony and artifact exists for a reason. Retrospectives aren't optional touchy-feely sessions—they're how you improve. Daily standups aren't status reports—they're coordination mechanisms. Learn the "why" before you decide to skip the "what."

Step 3: Pick one thing to fix. Don't try to fix everything at once. Choose your worst ScrumBut and address it. If you're skipping retrospectives, commit to holding them for the next three sprints. If your sprints are too long, cut them to two weeks.

Step 4: Protect the team. This is the Scrum Master's job. When stakeholders try to add mid-sprint scope, push back. When meetings threaten to overrun, facilitate better. When the organization pressures the team to skip ceremonies, be the shield.

Step 5: Measure the impact. Track what changes when you fix your ScrumBut patterns. Did your velocity stabilize? Did your team engagement improve? Did your quality metrics go up? Use data to prove that proper Scrum works.

When "Not Scrum" Is Actually OK

Here's a truth bomb: maybe you shouldn't be doing Scrum at all.

Scrum works brilliantly for complex product development with uncertain requirements. But if you're doing operational work, small enhancements, or projects with completely fixed scope, there might be better approaches.

Kanban might suit you better. Or a hybrid approach. Or even—gasp—waterfall for certain types of work.

The sin isn't in not doing Scrum. The sin is claiming you're doing Scrum while systematically undermining its core principles, then blaming "agile" when things go wrong.

Be honest about what you're doing and why. If Scrum doesn't fit, choose something else. But don't do ScrumBut and expect Scrum results.

The Bottom Line

ScrumBut is a symptom, not a disease. It's a signal that something in your organization is broken—maybe your understanding of Scrum, maybe your organizational culture, maybe your leadership support.

The solution isn't to double down on the compromise. It's to address the root cause.

Either commit to doing Scrum properly—all of it, even the uncomfortable parts—or admit you're doing something else and optimize for that instead.

Because the worst place to be is the middle: all the ceremony of Scrum with none of the agility. That's not agile. That's just exhausting.

So the next time you hear "We're doing Scrum, but..."—stop. Ask why. Question the assumption. Challenge the compromise.

Your team will thank you for it.