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.
