You Are Not 37signals

Why Shape Up might not be for you

This is a guest post of Roman Nikolaev. Roman is the CTO at Cambri, where he runs the product team in addition to the engineering organization. Roman's newsletter, High-Impact Engineering, is about real decisions from a working CTO, not theory or second-hand insights. It is rooted in twenty years of working in organizations of all sizes, from tiny startups to international mega-corporations.

A while ago, Benedikt published a post, “The Scrum decline: It’s three years later, and I was right”, about Scrum dying but Agile being alive. I agree with both, and especially the latter. Through the 2010s, Scrum became the default tool, and in most people’s heads, the two fused: Scrum = Agile. Kanban was around, too, but it felt more exotic. So the logic ran: if you want to be Agile, you do Scrum.

Back in the day, Scrum was revolutionary. We don’t need a full project plan; we can show progress and get feedback straight from the client. Hell yeah! But over time, the standard two-week sprint and the heavy ceremony started to feel like a chore rather than a source of flexibility. Then there’s the familiar failure mode: all the rituals in place, none of the agility. The classic situation — a fixed scope executed in sprints toward a fixed deadline.

My point is that Agile isn’t limited to Scrum. And Scrum only rarely, in my experience, very rarely, earns the name.

Benedikt proposes Shape Up as the alternative. I don’t think it’s a better one for most organizations.

Let’s start with the good. I see Shape Up as Agile for engineers: a small team, low meeting overhead, a six-week window to do real product work (design and code), plus dedicated time for technical debt and cleanup. Engineers get a long, uninterrupted stretch to focus, and they’re actively encouraged to keep the codebase clean. What’s not to like?

Quite a few things.

First, key product decisions sit with the shapers, not the team. Brief writing, evaluation, and betting all happen without the implementation team in the room. Scrum, for all its faults, keeps the product decision-maker inside the team’s loop: the Product Owner is present, reachable, and able to reprioritize mid-sprint. Shape Up pushes that decision upstream and freezes it: the bet is locked at the betting table, and the team then goes dark for six weeks. Yes, many Scrum implementations drift toward the same thing: the team is handed a feature, and the PO’s job is to slice it into stories and drop them in Jira. But even then, the decision-maker stays close and continuous, rather than upstream and frozen. Forced to choose, I pick Scrum, because the person who owns the “what” sits close enough to change course when reality does.

An ideal Agile team owns a value stream, not a feature or a brief. It has agency over what it delivers and how. Shape Up prescribes the what, and to some extent the how. I don’t like that.

My second problem is prescriptiveness. Shape Up is what 37signals built through years of iteration, and it fits their size, culture, and ownership structure. The key decision-makers are the company’s owners, and they sit at the betting table; they decide what gets done and how. The product is mature, the business is stable: no aggressive VC growth targets, no three-month runway, no shareholder pressure. They can afford eight-week cycles and a deliberate pace. More to the point, they can afford not to be able to redirect a bet mid-cycle, because they rarely need to. An early-stage company does. And yet this is exactly where the process keeps getting adopted, in companies where the ability to pivot on a week’s notice matters far more than a clean six-week block of focus.

None of this means Shape Up has nothing to offer. It introduces genuinely new concepts and gives them snappy names. The cooldown and the fixed-time / flexible-scope appetite may fit your context well. Or not. What I’d resist is blindly swallowing the whole process, shapers and eight-week cycles included, just because it works for 37signals.

I’m a fan of Agile as a principle. Adapting to internal and external feedback is the core of it, which is why I find it ironic when Agile coaches scold teams for not doing Scrum right. Isn’t that the whole point? Take what works, drop what doesn’t, fill the gaps.

Frameworks are a good starting point, nothing more. Adapt them to how you work; don’t bend the organization to fit the framework. The Agile Manifesto put it best: “Individuals and interactions over processes and tools.”

Thank you, Roman, for this response to my article! I‘m glad for our discussion.

Everyone who enjoyed this perspective: I deeply suggest you subscribe to Roman!

Best,

Benedikt

Please like ❤️ and restack 🔁 this article so others can find it, too. Thank you!

---