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.


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.


@jaygilmore thanks for your feedback.

I’m not hung up on it as a dogmatic treatise, I need to be able to compare it to something. The default mode of having senior members outside the team shape the work, is suboptimal in my opinion. That’s my criticism. If you decide to do it differently, then my criticism would evaporate. But they should change the default imo. Based on my experience of working with teams, hand-overs always lead to problems and lack of buy-in.

I never saw the section you’re referring to about shaping, could you please quote it for my reference?

If anything is wrong in my article, I’ll gladly update, that’s why I’m asking :-).

Hi Nelson,

1 and 2 are in the Shape Up guide. There’s your data :slight_smile:

3 is not a non-issue, as teams get formed to pick up the work. How do you do this? It’s a serious question, not covered by Shape Up. Contrasting to Scrum, where work gets assigned to teams. There it’s clear to me.

  1. SAFe sucks, agree with you. But there are far better approaches out there (including not using a Scaling Framework, Nexus, LeSS).

  2. It’s not a non-issue, as reflecting on the process is important to improve it

  3. If you believe that’s enough, you need to read more books on Product Management.

  4. I disagree, you get more buy-in if you involve people that do the work in decisions.