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.

2 Likes

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.

2 Likes

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.

2 Likes

@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.

Regardless of who is doing the shaping (doesn’t have too be the CEO like it is at Basecamp), the point of Shape Up is to reconsider how teams decide what they should build before they jump into to an execution process like Scrum.

The concept of questioning the backlog (or not having one?) and increasing the odds that what you build will actually deliver the expected value to the “user” is key in Shape Up. I hear from teams that they often waste time because they build the CEO’s idea and it turns out to *not be what customers value. So it’s less about who does the shaping, and more about that shaping happens at all and basing it on a different set on principles and process.

1 Like

I don’t think that you can easy compare them.
For me Shape Up is a missing element between traditional PM and Scrum. You don’t need a Scrum Master, PM, you do not need to prepare huge documentation and in the same time your engineers still feel responsible for the product. It looks really nice so thank you @rjs for writing it up:)

And btw there will always be some concerns with new methodologies:) I spent a lot of time on discussion about difference between traditional, waterfall methodology and Agile/Scrum. Both of them have issues:)

Apologies for the long post, I’m partly responding to this for my own thinking but thought I would share my responses anyway in case it’s helpful for others. I’ve definitely thought of, come across or had some of these objections myself when I first came across Shape Up.

Shaping is done by senior members outside of the team, possibly introducing waste and inefficient hand-overs.

In the Basecamp implementation yes, but the section [Adjust to Your Size] covers this in detail as someone mentioned above. It doesn’t have to be senior members, it could be developers, a team of “shapers”. For Basecamp and their size senior members makes sense for them, it might make sense for others.

I would also argue that even in Scrum work still comes from somewhere and typically with a much higher degree of waste and inefficiencies (huge design upfront, etc). Shape Up solves this by ensuring work is “shaped” to the right level first.

Teams get assigned to the work. I believe stable teams perform better than short-lived, temporary teams.

For me this is all about trade-offs. What’s your measurement for performing better? For us we find that short-temporary project teams work well to break down silos of information. We’re a small product engineering team overall though so we’re still able to build high psychological safety and all the necessary attributes of a high performing team. People can belong to more than one “team” some permanent, some temporary.

Again, this is likely something you’re going to have to adjust for your size. For very large companies I don’t see a reason you couldn’t have a large shape up team focused on an area within the business with enough people to form a couple of smaller temporary project teams (1-2 people each). The area within the business could be Marketing, or it could be a specific product vertical.

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?

There’s two sides to this. On one side, this is taken into account when assigning team members, I’m not going to give out some work to someone who has no chance of completing it - if they don’t understand the language for example. On the other side, I don’t mind giving out some work to someone who hasn’t got all the knowledge and insight on a particular part of the code. Having the team get comfortable with touching unfamiliar code reduces the risk of one person leaving who has all the knowledge of this one critical part of the product, it helps teams develop their skills and gets them to keep learning. The first part of the project is dedicated for the team to get in the code and see how it works.

It’s about being strategic with the work though, there are going to be some people who have a deeper understanding in a few areas and that’s good. If the work is particularly high-risk or needs it then we’ll make sure to align it to them.

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.

I agree I’ve not seen this in practice, I can only imagine theoretically some of the ways it could work. Adjusting for scale is critical here. Perhaps, a set of separate teams doing shape up focused on one area of the business as I suggested in a previous point could work? Perhaps, one large team of dedicated “shapers” designing, shaping, writing pitches could work? Maybe that team is formed of people with skills appropriate to shaping and they work in teams of 2? Maybe you go the other way and get teams to shape their own work as if they were a small startup again within the larger company? I think there’s lots of ways it could scale, but you need to be willing to try different things and find what works for you - follow the principles and ideas but adapt and test different ideas.

No moment of reflection built-in where people can chime in to improve the process. This is a missed opportunity.

There’s no reason you can’t put this in, for example we have a retro towards the end of every cycle. I also think this is something mentioned in the Shape Up book but I can’t find it so I’ll link to another Basecamp article that talks about their internal communication [Guide to Internal Communication] in there you’ll see they have what they call heartbeats every 6 weeks where people can reflect on the cycle, they also have a daily check-in and a weekly check-in. These feel like asynchronous versions of this reflection process. Again, if your team is more reliant on synchronous communication then a regular retrospective meeting may be better.

Shape Up does not cover validation of what you’ve delivered, just discovery and delivery.

It doesn’t, I struggled with that to begin with too. I think the key is that this happens as part of shaping the work but it’s not really spoken about in the book and it’s something you have to discover for yourself a little bit at the moment. Shaping is as much of turning an idea into a concept that can be built as it is about researching, testing, validating that what you’ve shipped works and how you can improve it. There’s some tweets from Ryan and a discussion thread on this forum about calling this part of the process Forging and how you work out what projects should be shaped.

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.

Again, adapting to your size is key. We have a fairly large betting table but it’s still mostly just key senior people but with representation across the business. It’s allowed us to be a lot more strategic about what’s valuable for us to spend our time on and what’s worth investing in. Those conversations would be hard to have if there were more people on the table with less context at the level of those decisions that are being made.

2 Likes