Shape Up Forum

Basecamp’s Shape Up: how different is it really from Scrum?

I discovered this article that is comparing Scrum and Shape Up. I like the article. In the end, the author is pointing out a few points where he doesn’t like the Shape Up approach:

  • Shaping is done by senior members outside of the team, possibly introducing waste and inefficient hand-overs.
  • Teams get assigned to the work. I believe stable teams perform better than short-lived, temporary teams.
  • How do you ensure teams have knowledge of the technical component they will be working on? Or is this taken into account when assigning team members?
  • Totally unclear how Shape Up will work with bigger teams or scale with many teams. My initial impression is that it does not seem extremely scalable.
  • No moment of reflection built-in where people can chime in to improve the process. This is a missed opportunity.
  • Shape Up does not cover validation of what you’ve delivered, just discovery and delivery.
  • The voice of people who will perform the work in the betting process seems small, apart from key senior people. It would be nice to include the team more in the decisions on what will be worked on, so there is more buy-in.

I would be curious to know how people would respond to those negative points. Thanks.

1 Like

These negatives are theoretical. The author hasn’t actually tried Shape Up to compare apples to apples. As someone at a company that’s Scrum except for my team, my two cents:

I haven’t seen data that validate bullets 1 or 2. Those are hypotheses.

3 is a non-issue, e.g. I wouldn’t put a Kotlin team on a Swift project, regardless of process.

4 is a legit ask. Haven’t seen anyone scale Shape Up. Then again, I would argue that scaled Scrum (e.g. SAFe) is lame. I always LOL when I witness PI planning, done by “certified” facilitators. Innovation theater at its worst.

5 is a non-issue. A Shape Up delivery team can build in whatever ceremonies they want. In fact, Shape Up is superior to Scrum in this regard. Not every team needs to retro every two weeks; I’ve sat in retros that were total time wasters.

For 6, if product validation/user testing is built into the shaped work, then it’s another non-issue.

7 is misleading. Shape Up gives the delivery team tons of freedom to speak up and voice how they want to do the work. Since task definition is left to the delivery team and not the shaping team, I think Shape Up is actually superior* in this regard.

IMO, at the end of the day, there’s no right or wrong here, no positives or negatives. Pick whichever framework works best for your team.

*Superior in practice, because I’ve seen many project leads dictate “how it has to be done” to their Scrum teams, which goes against Scrum’s principles.


My response to the author is he’s hung up on it as a dogmatic treatise. @rjs points out several times in the book to do what works with the people in your organization and explicitly showcases some examples of how it won’t fit every organization. Case in point, the Adjust to Your Size section talks about throwing out most of the structure when your team is small. It’s also my recollection that rjs points out that in some cases, the shapers may be the developers as well. In addition, rjs suggests that in some orgs it might make sense to allow the implementors to choose the projects rather than be given the projects. But, there’s a fair bit of autonomy described in the book that implementors will be able to make their own decisions on pace, scope, and how it gets implemented.