You Don't Need Scrum. You Need to Know What Ships Next Week.

Every small software team eventually has the meeting where someone says "we should do Scrum." Usually it follows a bad month — something slipped, a client was surprised, nobody could say why. Someone read an article, and now there's a proposal involving sprints, points, retros, and a fifteen-minute stand-up that will take forty.

Six weeks later the ceremonies have quietly stopped and everyone concludes agile doesn't work for them.

The framework wasn't the problem, and neither was the team. The problem is that Scrum was bought as an answer to a question nobody had actually asked out loud.

Name the real symptom first

Teams reaching for a process almost never say "our process is wrong." They say things that sound like this:

• Nobody can answer "what ships next week?" — including the people doing the work
• Things slip and nobody notices until someone outside asks
• Work gets started, half-finished, and left, and something new starts on top
• The same question — "where are we on that?" — gets asked ten times a week and answered from memory
• Two people spent Tuesday on the same problem, unknowingly
• Everything is "nearly done" for weeks at a time

Notice what these have in common. It isn't a missing framework. It's that the work is invisible — it lives in heads, chat threads, and half-remembered conversations, so the only way to learn the state of anything is to interrupt a human. Everything on that list is a symptom of invisibility.

That's the actual problem. Scrum is one possible answer to it, and quite a heavy one.

The three questions any working process must answer

Forget frameworks for a moment. A team's process is working if any person can find out, without interrupting anyone:

1. What is being worked on right now, and by whom?
2. What's next, in what order?
3. What's stuck, and who's unblocking it?

That's the whole bar. A team that can answer those three at any moment is functioning, whether they call it Scrum, Kanban, or nothing at all. A team that can't will keep failing at exactly the six things above, regardless of how many ceremonies it holds.

Most teams fail on 3 the hardest. Stuck work is invisible by nature — it isn't moving, so it produces no signal, and it silently costs more than anything else on the board. The single biggest improvement available to most teams is making "stuck" a visible state that someone is expected to look at daily.

The smallest thing that actually works

Four things. In our experience this is where the value is, and everything else is refinement:

One board, visible to everyone. Whatever tool you already have. Columns for the real states — not aspirational ones. Every piece of work exists on it. Work that isn't on the board doesn't exist, including the founder's urgent Slack request, which is the rule that makes or breaks this.

A limit on how much is in progress at once. The most underrated rule in all of project management: cap the "in progress" column. If it's full, you finish something before starting something. Teams with unlimited work-in-progress feel maximally busy and ship the least, because everything is 80% done and 80% done is worth nothing. Enforcing a limit is uncomfortable for about two weeks and then transforms throughput.

One short pass over the board, on a fixed day. Fifteen minutes, same time each week, reading the board top to bottom: what moved, what didn't, what's stuck. Not a status theatre where everyone recites their week — a review of the board, out loud, with the awkward silences that follow "this hasn't moved in nine days" left in.

One definition of "done." Most schedule surprises are definition problems, not estimation problems. If "done" means "the developer finished it" but the customer's definition is "I can use it," you will be surprised every single time, and it will feel like an estimating failure. Pick the customer's definition: done means shipped and in use.

Do those four and you can answer the three questions. That's the win, and it's available in an afternoon, without a framework, a certification, or a new tool.

So when does Scrum earn its overhead?

It isn't useless — it's specific. The heart of Scrum is the sprint: a fixed timebox, with a scope committed at the start and left alone until the end.

That protection is the product. It's genuinely valuable when the team's biggest problem is churn — when priorities change mid-week, when whoever shouted last sets the agenda, when nothing finishes because everything gets reordered. A sprint is a fence around two weeks of focus, and if you need that fence, Scrum's overhead buys you something real.

If your biggest problem is invisibility rather than churn — the six symptoms at the top — a Kanban board with a work-in-progress limit gets you there with a fraction of the ceremony, and lets urgent work in without breaking a commitment. Most small teams, most of the time, are in this second case. And there's an honest trap in the first case too: a lot of teams whose priorities genuinely change every three days adopt sprints and then break the sprint constantly, which is worse than not having one — you get the meetings and none of the protection.

Either way, pick the one that treats your actual symptom, and expect to change your mind later. The frameworks aren't teams. They're tools with a shape, and shapes fit some problems.

The thing that actually kills it

Here's why the six-weeks-and-it-stopped pattern is so consistent, and it has nothing to do with which framework got chosen: nobody was given the job of running it.

A process is not self-sustaining. Somebody has to keep the board honest, chase the stuck items, notice when a column is quietly overflowing, and run the weekly pass even in a busy week — especially in a busy week, which is exactly when a young process gets skipped and never comes back. If that job is nobody's, it becomes everybody's, which means it's the first thing dropped when a deadline appears.

So the question isn't "which framework." It's "who runs it, and is that a real part of their week?" If the honest answer is nobody, then adding process to your team will produce a burst of enthusiasm, a quiet decay, and a durable belief that agile doesn't work here.

Three ways that job gets covered: someone senior on the team owns it properly, with the time protected; you hire for it; or you buy it, which is part of what a managed engagement includes — for us, running the board and the cadence is part of Managed DevOps, specifically so it doesn't become another thing your team has to maintain. We sell that, so weigh this section accordingly. The point stands whoever does it: name the owner, or expect the decay.

Start here, this week

Don't adopt a framework. Do this:

Put every piece of work on one visible board, including the things currently living in chat. Cap what's in progress. Book fifteen minutes on Thursday to read the board out loud. Agree that done means shipped.

Then, at the end of the month, ask whether you can answer the three questions without interrupting anyone. If yes, you have a process, and its name doesn't matter. If no, you'll now be able to see which of the three is failing — and that's a fixable problem instead of a vague feeling that the team is disorganised.

If you'd like an outside read on how your work actually flows — and how it connects to the machinery that gets releases out the door, because a visible board in front of a release process nobody trusts just makes the fear visible — that's part of what our free DevOps review covers. Written down, free, yours to keep, including if you take the plan and run it yourselves.

And if it turns out you need Scrum after all, you'll know it from the evidence: you'll be able to see the churn on the board.