Javier Castro

Posted on Sep 9

Your Framework Isn't the Problem. Your Relationship to Your Framework Is.

#agileframeworkspractice

Teams keep switching from Scrum to Kanban to Shape Up looking for the methodology that will finally fix them — but the switch itself has become the ritual.

Picture a Monday morning standup that has drifted, over 18 months, into a 45-minute status theater. The Scrum board is updated. The sprint velocity is reported. The retrospective three days from now will surface the same three complaints it surfaced last quarter. The Scrum Master types notes nobody reads. And somewhere in the building, a VP is Googling "Shape Up methodology" for the third time this year.

This is the pattern. Teams don't abandon Scrum because they've tried it seriously and found it wanting. They abandon it because they've never actually done it — and they've confused going through the motions with going through the method.

The debate between Scrum, Kanban, and Shape Up has never been louder or less useful. Scrum is no longer treated as the only answer. Kanban, flow-based practices, and hybrid approaches are being explored — and in the best cases, thoughtfully combined with Scrum rather than replacing it entirely. But even that framing, from Scrum.org's own 2025 retrospective, reveals the problem: the conversation is still primarily about framework selection, not about the much harder work of organizational honesty.

Here is the claim worth arguing: most teams that switch frameworks aren't fixing a methodology problem. They're using a methodology switch to avoid facing a cultural one.

The Ceremony Tax Nobody Wants to Pay

Scrum's overhead is real. Taking a whole team away from their work for several hours a month is a genuine cost — and the Scrum framework caps the time allocated to sprint planning, daily scrums, reviews, and retrospectives at 20 hours for a 4-week sprint, which represents just over 12% of the entire development effort. That's not nothing. For a team of eight engineers, you're burning a non-trivial amount of collective focus before anyone writes a line of code.

But the ceremonies themselves are rarely the real problem. Agile events aren't failing because people lack training. They're failing because organizations adopted the rituals while rejecting the transparency, trust, and adaptation that make them work. And often, the dysfunction of mechanical ceremonies isn't a bug — it's a feature. Dysfunction, when institutionalized, becomes comfortable. The zombie standup continues because canceling it would require someone to admit it was never working.

The Daily Scrum becomes a status report. Sprint Planning confirms decisions a small circle made last week without the team. The Retrospective surfaces the same three issues it surfaced six months ago, unchanged. The Sprint Review is a demo, polite applause, and then everyone leaves to do something meaningful.

That last sentence has the sting of recognition because it describes roughly 60% of the Scrum implementations in any mid-size software company right now.

When Kanban Isn't Liberation — It's Avoidance

The flight to Kanban often starts with exactly this frustration. A team documents, in their fourteenth retrospective, that sprint planning takes too long and that they keep carrying stories across sprint boundaries. The solution proposed is nearly always the same: ditch the sprints.

One team at mobile advertising company Marchex, documented through the Agile Alliance, found that their Scrum practices stopped working when their work type shifted. They had been successfully using Scrum for more than two years, but morale deteriorated as it became harder to execute on sprint plans. Their eventual switch to Kanban made sense — they were moving into a more fluid, exploratory product development context where two-week sprint goals genuinely couldn't be committed to in advance.

A developer who had made the transition told her former manager she liked the Kanban style for two reasons: the team focused on the top one or two stories from the backlog, and when those were done, they moved to the next. She enjoyed the simplicity of picking the top story and finishing the work — the process felt more manageable because their stories were much smaller in scope.

That is a real and legitimate case for Kanban. You choose Kanban over Scrum when it is impossible to plan a Sprint and create a Sprint Goal — a classic example being an IT helpdesk. Unpredictable, interrupt-driven, maintenance-heavy work genuinely resists sprint commitments. Trying to force it into two-week boxes isn't discipline — it's denial.

But most teams switching to Kanban aren't helpdesks. They're product teams that found sprint planning uncomfortable. And Kanban has a quiet failure mode that's harder to see than Scrum's. Everything looks busy, boards are full, policies are written down — but no one actually owns the flow. It feels like motion without control. Kanban boards make work visible. They do nothing about who decides what gets prioritized, at what rate, and whether the team has the authority to say no to new work entering the system.

An organization might balk at the deeper change required for Scrum and settle for a Kanban implementation instead, intending to lean out existing workflows incrementally. But when Kanban boards are set up across pseudo-teams without genuine ownership, the expected transformation simply doesn't arrive. You get visibility into dysfunction, not the elimination of it.

Shape Up's Honest Bargain

Then there's Shape Up, Basecamp's framework, published in 2019 and still drawing converts. Its appeal is structural. Basecamp is not into waterfall or agile or Scrum. They don't line walls with Post-it notes. They don't do daily stand-ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking — none of that.

It's a bracing read if you've sat through your share of backlog grooming sessions. The core concept is the "appetite" — and it's genuinely different from what Scrum calls an estimate. An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. The appetite functions as a creative constraint on the design process.

Basecamp reduces risk in the planning process by capping bets to six weeks. If a project runs over, by default it doesn't get an extension. This "circuit breaker" ensures the team doesn't invest multiples of the original appetite on a concept that needs rethinking first.

That's a philosophically clean idea. But it comes with a specific precondition that most teams gloss over when they're excited about adopting something new: Shape Up gives full responsibility to a small integrated team of designers and programmers who define their own tasks, make adjustments to scope, and work together to build vertical slices of the product one at a time. This is completely different from methodologies where managers chop up the work and programmers act like ticket-takers.

Read that again. Shape Up requires that the people doing the building also have genuine authority over scope. In organizations where product managers, engineering managers, and delivery leads each hold partial authority over the work, Shape Up's shaping track collapses into a different flavor of the same planning theater teams were trying to escape. You've just redecorated the room.

One engineering team described trying Scrum on a fast-moving web team as unnatural and forced. They moved to a more fluid way of working — a Kanban approach — stopped caring about sprints, dropped most Scrum rituals, and focused simply on knowing what they were working on now and what they'd get done next. That worked for that team, in that context, with those specific reporting structures. It's not a universal prescription.

What Big Tech Actually Does (And Why It's Not Entirely Reproducible)

A survey of how tech projects run across the industry, covered extensively by Gergely Orosz in The Pragmatic Engineer, highlights Scrum being absent from Big Tech. Google, Meta, Stripe, Uber — these organizations don't run on Scrum. Teams are generally free to choose their own project management methodology. Many go with an RFC-like planning process, iterate on building, and ship within a few weeks. Others use more Kanban-like processes, working on the highest priority items.

This is frequently cited as evidence that Scrum is obsolete. It isn't. A different interpretation holds: Big Tech's flexible, low-ceremony approach is only possible because of what's already in place around it. Infrastructure and developer tooling remove the need for many Scrum rituals. Scrum's requirement to demo to the Product Owner and sign off the work assumes the Product Owner is the one who can validate the work as done to spec — and that the work isn't being shipped before that sign-off. When you have world-class CI/CD pipelines, extensive observability, and engineers who've been trusted with production access for years, the ceremony overhead that Scrum was designed to manage largely disappears. The structure dissolves because the underlying trust, tooling, and team capability have replaced it.

Most teams adopting Shape Up or going no-ceremony Kanban don't have those prerequisites. They're removing the scaffold before the concrete has set.

The Fair Counterargument

To be clear: Scrum is absolutely worth criticizing. Its certification industry has spawned a consultant class that made ritual compliance its product and called it agility. Mechanical Agile — where an organization buys the artifacts, sends people to training, installs Jira, and declares itself agile — is a real and widespread failure mode. The proliferation of Scrum Masters who function as meeting schedulers rather than impediment removers is a genuine organizational tax.

And the healthiest organizations aren't dogmatic. They ask what problem they are trying to solve and allow their teams to choose practices accordingly. That is exactly the right instinct. Framework pluralism is legitimate.

But "allow teams to choose" is very different from "switch frameworks every 18 months when the current one fails to overcome the organization's structural dysfunctions." Teams struggling often had little to do with the methodologies. People mentioned lack of vision, good engineers leaving, lack of transparency, or poor tooling as reasons why things went badly. For these teams, no change of methodology would help because the issues ran deeper.

The problem is almost never Scrum. It's almost never Kanban. And it's almost never Shape Up. The problem is usually that real decisions get made outside the room where the framework thinks they happen, that backlogs are political documents dressed in engineering language, and that the people running the ceremonies don't have the authority to act on what the ceremonies reveal.

We are not paid to practice Scrum. We are paid to solve customer problems within given constraints while contributing to our organization's sustainability. Scrum is a means, not an end. The moment you optimize for "doing Scrum correctly" instead of delivering value, you've lost the plot. The same is equally true for Kanban. And for Shape Up.

The Switch Teams Actually Need

The practitioners most worth listening to are the ones who've been through multiple framework transitions and come out the other side pragmatic rather than evangelical. Their consistent observation is that what changed wasn't the process — it was the conversation the process forced. A retrospective that finally held people accountable. A betting table that required someone to decide what not to build. A WIP limit that made the bottleneck impossible to ignore.

The increasing adoption of Kanban practices within the Scrum framework — particularly the decision to limit work in progress — is a genuinely positive trend. When a team limits the number of work items in any active state at a given time, it seems like a small change, but it has a profound impact on focus and helps teams deliver value sooner because they aren't multitasking as much.

That's not a framework switch. That's a team deciding to take their existing framework seriously.

The frameworks themselves — Scrum, Kanban, Shape Up — all contain enough truth to be useful in the right hands, with the right organizational conditions, and with leadership willing to actually change behavior rather than change whiteboards.

The uncomfortable version of that sentence: if your last three framework switches didn't improve delivery, the fourth one probably isn't the answer either. And somewhere in that building, a VP is still Googling.

DEV Community