- What makes Shape Up different?
- When Shape Up works well
- When it falls short
- So what should you actually do?
- Further reading
I keep coming back to the same frustration with how we build software. Not the code, the process around it. Sprint planning that eats three hours. Standups that turn into debugging sessions. A backlog so long nobody even scrolls to the bottom anymore.
Agile was supposed to fix all this. Scrum, Kanban, SAFe, whatever. And those frameworks helped, I won't deny that. But at some point things drifted. Two-week sprints started fragmenting work into artificial chunks. Context switching never stopped. There was this constant pressure to estimate story points for work we barely understood yet, and I started noticing we were spending more time managing the process than actually building things.
Then I found Shape Up, the approach from Basecamp (now 37signals). It described exactly what was bothering me, better than I could.
What makes Shape Up different?
Shape Up is not Agile with different labels. The structure is different enough that it changes how you think about planning.
Work in six-week cycles. Not two weeks. Six. Long enough to build something real, short enough that you can't hide. "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 for bugs, tech debt, or just breathing.
Before a cycle starts, senior people do what Basecamp calls "shaping." They take raw ideas and turn them into pitches with clear limits. Not detailed specs, but something with clear boundaries and a sense of what you're not going to build. That last part is important.
Then small teams, usually a designer and one or two programmers, take the shaped project and run with it. No daily standups. No one hovering for status updates. The time is fixed at six weeks, but the scope flexes. If something is taking too long, you cut scope, not time.
There's no backlog. Ideas that don't make it into a cycle just disappear. If they matter, they'll resurface. If they don't, you saved yourself from a list of tickets nobody will ever touch.
When Shape Up works well
I've seen it work for product teams that are tired of the sprint treadmill. It fits when you're building features that need real design thinking, the kind of work that breaks apart when you force it into two-week slices.
It works when your team is experienced enough to work without someone checking on them every day. When people can make decisions without approval for every small thing, and when they'll actually say something when they're stuck instead of waiting for a standup.
Six weeks lets you sit with a problem long enough to solve it properly. A couple people I've talked to said they felt less scattered, and one mentioned actually having time to think about edge cases instead of just filing them as follow-up tickets. I've had the same feeling on longer projects.
The no-backlog thing is better than it sounds. You stop maintaining a guilt list of things you'll never get to. You stop feeling bad about the tickets that have been sitting there for a year and a half. Every cycle is a clean slate.
When it falls short
Shape Up is not a universal fix.
If most of your work is small customer requests and bug fixes, the six-week cycle feels heavy. Sometimes you just need to knock out twenty little improvements, and trying to shape each one into a project is forced. The cooldown weeks help some, but if 80% of your work looks like this, you're probably fighting the framework.
Shaping requires people who understand both the business and the technology. If you don't have senior folks who can do this well, you end up with vague projects that either blow up in scope or leave teams stuck. Good shaping is hard. It takes practice.
Teams that need predictability may struggle too. "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." If your stakeholders need firm dates on specific features, the flexible scope will create problems.
It's also wrong for true discovery mode. Six weeks is too much commitment when you need to pivot every few days based on user feedback. Shape Up assumes you have some idea of what you're building.
And if your organization is deeply invested in Agile tooling, velocity charts, burndown graphs, story points, the transition is a hard sell. Some teams aren't ready to give those up, and pushing Shape Up into that environment just creates a different kind of process overhead.
So what should you actually do?
The useful question isn't "is Shape Up better than Agile?" It's "what's actually broken in how we work right now?"
If your problem is fragmented work and constant context switching, Shape Up is worth trying. If you're drowning in process overhead, read the book and see what makes sense for you. But if you mostly need to ship small changes on a predictable schedule, you probably don't need to change anything.
I don't really care if Shape Up is "the right framework." What I care about is whether teams are honest about why they work the way they do. Most of us inherited our process from a previous team or a blog post from 2015. Maybe it's time to revisit that.
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 - the company behind Basecamp, Ruby on Rails, and several opinionated books about how to run a software business
Edits:
- 2026-02-07: Added table of contents with anchor links