Shape Up is for features, not all development work
I'm seeing a pattern among successful Shape Up teams.
Companies first try Shape Up on a product team that builds features. They discover a new rhythm of shaping and shipping meaningful changes, and it feels like a victory.
Then, they think "well since Shape Up is working ... we should try to do all development this way."
But it turns out, that's not the case. Feature work is a very different animal from other kinds of work.
Feature work
The kind of work that Shape Up is good for — feature work — meets two conditions:
- The effort is meaningfully large (2 to 6 weeks).
- The betting table controls the schedule of every person involved in implementing it.
There are two very different types of work that don't meet these conditions.
Reactive work
Reactive work is small work (< 3 days) that someone outside the product team urgently wants. It comes from Support ("fix this bug"), Marketing ("add this promotion"), Operations ("look into this exception"), etc.
Reactive work is too small to put into a pitch. And there's too much urgency to wait six weeks for a future cycle.
That's why I advise teams to explicitly not use Shape Up for reactive work. Treat it as a distinct process with its own tooling. A regularly prioritized backlog + kanban setup is much closer to the right approach than pitches and cycles. To not interrupt the Shape Up teams, reserved capacity for reactive work ("these two programmers are on reactive work this cycle"). Many teams choose to rotate people between the two pools.
Cross-party integrations
Sometimes a project requires integrating with a third party. For example, you're partnering with a bank, and your effort requires them to make some API changes.
No matter what agreements you make, at the end of the day, their schedule isn't yours. They will get interrupted with something more important on their end, which will pause your project and blow up the cycle.
This is another case where a just-in-time, kanban-style model is going to work better. Set the expectation up front that you don't know when the external dependencies will arrive, and do other available work while you wait.
Note that a "third party" can be internal. From a Shape Up perspective, anybody who isn't scheduled from the betting table is considered "external." They are a dependency you can't control, which breaks all the expectations about autonomy that Shape Up requires.
Different processes create clarity
When Shape Up is supposed to do everything, the results will be diluted. Setting up different processes clarifies everyone's understanding. People will see that the way they work matches the circumstances. There will be more of a feeling that we're doing something "because it works for this" and not "because we should" or "because Shape Up says." And there won't be tension from other teams, where Shape Up doesn't help them, because they are free to evolve the right processes.