I’ve been getting asked recently what I think of @rjs/@basecamp’s Shape Up. A quick thread:
1. Absolutely read the book. It is good. basecamp.com/shapeup
2. Detailed information about how a company works is always helpful, and this is no exception. It gets specific!
1. Absolutely read the book. It is good. basecamp.com/shapeup
2. Detailed information about how a company works is always helpful, and this is no exception. It gets specific!
3. Whenever a company goes deep (which I love), it is also good to ask “What are the first principles here?“
SU does a *reasonable* job in this respect. If you’re a prod dev nerd you can pick them out easily. If not it might be tougher.
SU does a *reasonable* job in this respect. If you’re a prod dev nerd you can pick them out easily. If not it might be tougher.
4. This happened with the “Spotify Method” if you remember. There were lots of first principles mentioned — or implied — by @henrikkniberg (e.g. aligned autonomy or the purpose of chapters/squads, etc.), but it become very easy to Copy-Paste without understanding them.
5. A great example is using a 6w timebox as an enabling constraint. “Sprints Suck!” right? But there’s nuance in the book. Teams are expected to get going quickly (3 days!), work closely together, etc.
Plenty of teams use nested cadences. The Q is why do they work?
Plenty of teams use nested cadences. The Q is why do they work?
6. In my work, I meet teams that have organically arrived at ways of working very similar to Shape Up (and very different!). And they’ve typically done that by thinking about first principles — enabling constraints, optionality, risk, focus, etc. — so try to pick those out.
7. Another area is around decision authority/autonomy, etc. Basecamp has a specific culture. Their engineers & designers like to work in certain ways. They don’t mind being handed a bet by @rjs /@jasonfried . Which works for them, but may not work for you. Again, first principles
8. You get the idea ... ask “Why does this work at @basecamp and what can I learn from that?” It very well may be that a 6 week timebox may be hard. Shorten it. Or that you need more/less shaping. Do it. Or want more decision autonomy for your teams. Do that.
9. My main critique of the book is that they don’t go out of their way to call out first principles, or prior work. Much of it is positioned as new, which it may actually be for them, so I assume no malice in that regard.
Some of the best stuff is reinvented/remixed in a vacuum
Some of the best stuff is reinvented/remixed in a vacuum
10. It makes up for this by giving tons of detail, which is often missing in books about first principles. It’s a juggling act. You almost need an annotated version. I recently did this for a friend related to Shape Up (adding sources and prior work). I might share it.
12. I’ve seen (and been on) teams that have designed interesting ways of working that identified as “Agile”, and as “We Hate Agile”. So ask yourself:
What about your current environment made it hard to adapt your own way of working? Knowledge? Experience? Or Process/Politics?
What about your current environment made it hard to adapt your own way of working? Knowledge? Experience? Or Process/Politics?
PS. Please, please, please considering writing about how you work. It is sad, in a way, that our vocabulary is dominated by Spotify, Basecamp, Drift, Google, Amazon, etc ... the people who have the time to write in detail.
There are so many interesting ways out there.
There are so many interesting ways out there.
As a follow up, I wrote this bullet/notes based review:
