What Scrum actually is, and when you're better off without it

Scrum has a bad reputation on some teams, and it's almost always for the same reason: the ritual got adopted without the purpose behind it. A forty-minute standup that's supposed to take ten. Two-week sprints nobody actually closes on time. A board that gets updated right before the meeting instead of throughout the week. That's not Scrum working badly — it's theater wearing Scrum's name.

The framework itself is short. You can explain all of it in half a page. Everything past that is team discipline, and no process substitutes for that.

What it actually solves

Scrum exists for one specific problem: building something whose final scope isn't fully known up front, delivering value along the way instead of betting everything on a distant deadline. If the work is predictable and repeatable — installing the same system at branch number fifteen — Scrum adds nothing a checklist wouldn't handle better.

The three roles

• Product Owner. Decides what gets built and in what order, representing the business or the client. One person, not a committee — the responsibility to prioritize doesn't survive being split.
• Scrum Master. Not a project manager. Protects the process: that the team can focus, that blockers get resolved, that meetings serve their purpose and end on time.
• Development team. Decides how it gets built. Cross-functional and self-organizing — nobody outside the team assigns individual tasks.

The five events

Event	What it's for	Typical length
Sprint	The full cycle: plan, build, deliver	1 to 4 weeks, fixed
Sprint Planning	Choose what enters the sprint and how to approach it	2 hours per week of sprint
Daily Scrum	Sync the team, catch blockers early	15 minutes, standing
Sprint Review	Show what got built and gather real feedback	1 hour per week of sprint
Retrospective	Adjust how the team works, not what it builds	45 minutes per week of sprint

The Daily is the one that drifts the most. It isn't a status report for a manager — it's the team coordinating with itself. The moment it starts feeling like an accounting exercise, it's stopped doing its job.

The three artifacts

• Product Backlog. Everything that could be built, ordered by priority. Alive — it changes every time the team learns something new.
• Sprint Backlog. What the team committed to deliver this sprint, plus the plan to get there.
• Increment. What's actually finished at the end of the sprint, in a state that could be shown or shipped — not "almost done."

That last point is the one that gets negotiated down the most. An increment that needs another week of polish before it can be shown isn't an increment — it's work in progress with a label on it.

Signs the team is carrying it without needing to

• The sprint never closes clean. If two out of every three sprints end with tasks that "roll over to the next one," the problem isn't discipline — the team is committing to more than it delivers, sprint after sprint, without adjusting the estimate.
• Meetings happen because the calendar has them, not because they solve anything. A Daily where nobody coordinates anything, only reports status, is a status meeting wearing a different name.
• The Product Owner has no real authority to prioritize. If every scope decision needs three levels of sign-off, the role exists in name only.
• The team is one or two people. Scrum coordinates a team. With one person, coordination isn't the problem that needs solving.

When something simpler is the better call

A Kanban board — status columns, limited work in progress, no fixed sprints or ceremonies — usually works better for support, maintenance and work that arrives continuously and unpredictably rather than in batches. And for a team of one or two, the useful discipline is simply writing down what's getting done this week and reviewing it at the end, with no framework name attached.

Our approach

At id3a we use Scrum on projects where the scope gets discovered along the way — most custom software falls into that category — and Kanban for maintenance and support, where work trickles in instead of arriving in sprints. The first question we ask isn't "which methodology do you prefer," it's "how predictable is what needs to get built." The answer usually answers the first question on its own.

Let's talk about how to organize your next project