ScrumBut: When Agile Becomes Agile-ish

“We do Scrum, but…” If you’ve been in Agile long enough, you’ve heard this phrase. Maybe you’ve even said it yourself. It’s the telltale sign that a team has fallen into ScrumBut—a dangerous trap where Scrum is implemented partially, selectively, or incorrectly.

Scrum isn’t just about stand-ups and sprint planning. It’s a framework designed to help teams build, inspect, and adapt in a way that maximizes value and minimizes waste. But when organizations cherry-pick Scrum practices while ignoring its fundamental principles, they create an “Agile-ish” environment that dilutes Scrum’s effectiveness.

Let’s break down the common ScrumButs, why they happen, and how to fix them before they turn your Agile transformation into a waterfall disaster with daily stand-ups.

Common ScrumButs and Their Consequences

1. “We do Scrum, but we don’t do retrospectives.”

The Problem: The team moves from sprint to sprint without stopping to reflect. Without retrospectives, mistakes are repeated, and improvement is nonexistent.

The Impact:

• Teams feel stuck, frustrated, and unheard.
• Performance stagnates because no lessons are captured.
• Small issues snowball into big process failures.

The Fix: Make retros non-negotiable. Keep them short, focused, and action-oriented. Use techniques like Start-Stop-Continue or Sailboat Retros to encourage engagement. Most importantly—act on the feedback! A retrospective without change is just another meeting.

2. “We do Scrum, but we don’t have a dedicated Product Owner.”

The Problem: The Product Owner role is split among multiple stakeholders, or worse, it’s absent altogether. The team lacks clear priorities and receives conflicting direction.

The Impact:

• Constant scope changes derail the sprint.
• The backlog becomes a dumping ground for random requests.
• Developers waste time guessing what the business actually wants.

The Fix: A dedicated, empowered Product Owner is critical. They should be embedded in the team, actively refining the backlog, and acting as the single source of truth for priorities. If leadership won’t commit to a full-time PO, escalate the issue—because without one, you’re not doing Scrum.

3. “We do Scrum, but we plan sprints around individual assignments.”

The Problem: Instead of collaborating, developers work in silos. Work is planned around individuals rather than cross-functional team efforts.

The Impact:

• Dependencies slow down the team.
• Knowledge remains locked in individual heads.
• Scrum becomes a task list instead of a team-based framework.

The Fix: Encourage cross-functional collaboration by breaking down silos. Use pair programming, mob programming, or knowledge-sharing sessions to spread expertise. The goal is team ownership of work, not fragmented individual efforts.

4. “We do Scrum, but we estimate in hours instead of story points.”

The Problem: Teams try to estimate work in exact hours rather than relative effort. Story points—an Agile best practice—are ignored.

The Impact:

• Velocity becomes meaningless.
• Developers feel micromanaged by unrealistic time estimates.
• The focus shifts from value delivered to hours logged.

The Fix: Embrace relative sizing. Story points encourage teams to think about complexity, risk, and effort—rather than a rigid time estimate. If leadership insists on hourly estimates, educate them on why story points improve forecasting and team autonomy.

5. “We do Scrum, but we skip daily stand-ups when busy.”

The Problem: Stand-ups are skipped when workloads get heavy, making collaboration suffer.

The Impact:

• Blockers go unnoticed.
• Work falls out of sync, causing unnecessary delays.
• Scrum becomes “waterfall with post-it notes.”

The Fix: Stand-ups should be short, focused, and valuable. Keep them under 15 minutes and structured around progress toward the sprint goal and adjustments to meet the sprint goal.

Oh, yeah remove the Scrum Master and Product Owner!

No side discussions, no status updates—just alignment and problem-solving. If your team thinks stand-ups are a waste of time, it’s likely they’re being done wrong, not that they’re unnecessary.

Why ScrumButs Happen

• Organizational Resistance to Change – Legacy processes clash with Agile principles.
• Misunderstanding Scrum’s Purpose – Teams treat Scrum as a checklist rather than a mindset.
• Pressure to Deliver Faster – Cutting corners seems tempting but leads to long-term failure.
• Lack of Agile Coaching – Without training, teams struggle to implement Scrum effectively.

How to Transition from ScrumBut to True Scrum

• Educate the Team – Reinforce Agile principles and why each Scrum event exists.
• Start Small, Fix One Thing at a Time – Don’t overhaul everything overnight.
• Get Leadership Buy-In – Ensure executives support Agile adoption.
• Hold Teams Accountable – Have a Scrum Master enforce best practices.
• Measure Success – Use team-driven metrics (not just velocity) to track improvements.

Conclusion: Stop Doing Agile-ish, Start Doing Agile Right

Scrum is a powerful framework—but only when it’s implemented correctly. ScrumBut isn’t just a minor inconvenience—it undermines agility, slows teams down, and prevents real transformation.

Ask yourself: Is your team truly doing Scrum, or just checking boxes?

Try these things:

• Audit your team’s Scrum process. Identify your ScrumButs.
• Commit to fixing one major issue at a time. Small changes lead to big results.
• Be an advocate for Agile done right. Challenge practices that dilute Scrum’s effectiveness.

🚀 Want help fixing ScrumButs in your organization? Share your biggest challenge in the comments or book a coaching session today!