agile #scrum #shape-up #basecamp #37-signals #kanban

I've been thinking a lot lately about how we build software. Not the code itself—that's the easy part, really—but the process. The endless ceremonies, the sprint planning that somehow takes three hours, the daily standups that drift into problem-solving sessions, the backlog that's become this unwieldy beast no one wants to groom.

For years, we've been told that Agile is the answer. Scrum, Kanban, SAFe—pick your flavor. And look, these frameworks have helped countless teams ship better software. But somewhere along the way, something started feeling off. The two-week sprints that fragment work into artificial chunks. The constant context switching without possibility to think deeply about the problem on the table. The weird pressure to estimate story points for work we barely understand yet. The nagging feeling that we're spending more time managing the process than actually building things.

Then I stumbled onto Shape Up, the approach developed by Basecamp (now 37signals), and it felt like someone had articulated frustrations I didn't even know I had.

What Makes Shape Up Different?

Shape Up isn't just Agile with different terminology. It's a fundamentally different way of thinking about product development cycles.

The core idea Work in six-week cycles. Not two weeks. Six. Long enough to build something meaningful, short enough to stay focused. "Plus it gives you about eight chances a year to recalibrate and decide what to work on next." (see: 37signals). Between cycles, there's a two-week cooldown where teams can breathe, fix bugs, explore ideas, or just catch up on that technical debt everyone's been ignoring.

But here's where it gets interesting: before a cycle starts, senior people do what Basecamp calls "shaping." They take raw ideas and turn them into bounded, well-considered pitches. Not detailed specifications—that would defeat the purpose—but something with clear boundaries, key insights, and thoughtful limitations. Crucially, they also identify what you're not going to build.

Then small teams (typically a designer and one or two programmers) take these shaped projects and run with them. No daily standups. No one breathing down their necks asking for status updates. They're trusted to figure out the details, make trade-offs, and solve problems. The appetite is fixed—six weeks—but the scope is flexible within reason. If something's taking too long, you cut scope, not time.

There's no backlog. Ideas that don't make it into a cycle just… don't exist anymore. If they're good, they'll come back. If they're not, well, you just saved yourself from maintaining a graveyard of forgotten tickets.

When Shape Up Really Shines

I've seen Shape Up work beautifully for product teams that are tired of the sprint treadmill. It's particularly powerful when you're building features that need genuine design thinking and integration work—the kind of projects that get mangled when you try to slice them into two-week chunks.

It works when your team is experienced enough to operate with autonomy. When people can make good decisions without needing approval for every little thing. When you trust your developers to be adults who can communicate when they're stuck without needing a daily check-in.

The six-week cycles are a game-changer for work that has natural complexity. You can actually design something properly, build it thoughtfully, and refine it without this artificial urgency every two weeks. Teams report feeling less fragmented, more focused, and paradoxically more creative because they have room to think.

The "no backlog" philosophy is incredibly liberating. You stop maintaining this guilt-inducing list of things you'll never do. You stop feeling bad about all those tickets that have been sitting there for eighteen months. Each cycle is a fresh start.

When It Might Not Be Your Best Bet - Shape Up isn't a universal solution.

If you're maintaining a mature product with lots of small customer requests and bug fixes, the six-week cycle might feel cumbersome. Sometimes you just need to knock out twenty small improvements, and cramming them into a "shaped" project feels forced. The cooldown weeks help, but if this is 80% of your work, you might be fighting the framework.

It assumes a certain organizational maturity. The shaping process requires people who really understand both the business and the technology. If you don't have senior folks who can do this well, you'll end up with poorly defined projects that either explode in scope or leave teams floundering. And honestly? Good shaping is hard. It's a skill that takes time to develop.

Shape Up can be rough for teams that need predictability. If you're in a context where stakeholders need firm commitments about exactly what ships when, the flexible scope model might cause friction. "We'll ship something good in six weeks" is a very different promise than "We'll deliver these fourteen story points by the end of Sprint 23."

It's also not ideal if you're in true discovery mode, experimenting rapidly with prototypes to find product-market fit. The six-week commitment is too heavy when you need to pivot every few days based on user feedback. Shape Up assumes you have some clarity about what you're building.

And let's be honest: if your organization is deeply committed to Agile ceremonies, metrics, and tooling, the transition can be difficult. No velocity charts. No burndown graphs. No story points. Some organizations aren't ready to let go of those security blankets.

The Real Question

The more I dig into Shape Up, the more I think the real question isn't "Is Shape Up better than Agile?" It's "What problems are we actually trying to solve?"

Are you frustrated by fragmented work and constant context switching? Shape Up might help. Are you drowning in process overhead and want to give teams more autonomy? Worth exploring. Do you need to ship lots of small changes quickly and predictably? Maybe stick with what you know.

Shape Up' is opinionated. It makes trade-offs. It acknowledges that different contexts need different approaches.

Not that Shape Up is better or worse than Scrum or Kanban, but that we should be more thoughtful about why we work the way we do. Remember: dare to question the defaults.

Further reading

• overview article on shape up method - Shape Up: a complete guide to this new development methodology (2024)
• free book on shape up - Shape Up: Stop Running in Circles and Ship Work that Matters
• 37signals - This site is a catalog of liberating ideas about how they (company behind basecamp, Ruby on Rails,...) works, do business, live...