Unpacking Shapeup
A guide for people looking to implement parts of Shapeup but are unsure how
Since its release, Shapeup (the book that describes software development at Basecamp) has made many PMs eager to implement its practices. They start by cherry-picking its patterns. This is not the best approach. As Ryan Singer (the author) says:
"The Shape Up method presented in this book is tightly interwoven. It may take some thought and experimentation to pull out the right pieces and adapt them to your team."
This article is for PMs looking to implement parts of Shapeup but are unsure how. To help, I have identified Shapeup's 15 core patterns and visualized the relationship between them. Now when you want to implement Appetite, you can quickly identify that it requires Uninterrupted time in the cycle to get off the ground. Interestingly, the resulting map also uncovers a key principle that underpins Shapeup.
Let me walk you through it.
The 15 core patterns of Shapeup
This is my list of the patterns in Shapeup in order of appearance.
Each pattern links to the part in the book that explains it.
Part 1: Shaping
Part 2: Betting
Part 3: Building
Mapping the relationships
Next, I logged the causal relationships between these patterns in a Google sheet.
For example: Having a Cool-down is important if you want to run uninterrupted cycles because:
"If we were to run six-week cycles back to back, there wouldn’t be any time to breathe and think about what’s next." - Shapeup
After I was satisfied with these relationships, I mapped them on a Miro board.
Besides showing the dependencies beautifully, something else stands out. Almost all of Shapeup's patterns revolve around making teams responsible for projects instead of tasks. This focus is not a coincidence.
Leave room for decisions when building
The folks at Basecamp believe that many design decisions should (and can) only be made -closest to where the real work happens- on the proverbial construction site. There are tradeoffs that only emerge during actual development and you should give your teams the freedom and responsibility to make them.
This belief runs throughout the book. Just some of the many examples (emphasis mine):
Work that’s too fine, too early commits everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.
Projects also turn out better when the team is given responsibility to look after the whole. Nobody can predict at the beginning of a project what exactly will need to be done for all the pieces to come together properly. What works on paper almost never works exactly as designed in practice. The designers and programmers doing the real work are in the best position to make changes and adjustments or spot missing pieces.
When teams are assigned individual tasks, each person can execute their little piece without feeling responsible for judging how all the pieces fit together. Planning up front makes you blind to the reality along the way.
The team naturally starts off with some imagined tasks—the ones they assume they’re going to have to do just by thinking about the problem. Then, as they get their hands dirty, they discover all kinds of other things that we didn’t know in advance. These unexpected details make up the true bulk of the project and sometimes present the hardest challenges.
The way to really figure out what needs to be done is to start doing real work.
This principle -of giving teams autonomy within the bounds of a shaped pitch- partly comes from what Jason and David (Basecamp's founders) were already doing intuitively and from Ryan's research into Christopher Alexander (architect & design theorist)
In a nutshell: Don't try to think it all up at once, but let the design unfold step-by-step in the act of building. And this unfolding can only happen, when the 'builders' have the freedom to do so. I can recommend Ryan Singer's introduction to Christopher Alexander if you want to go down the rabbit hole.
The Virtuous Cycle of Autonomy & Shaping
When we zoom out further, something else stands out.
"These concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously." - Shapeup
It strikes me how the corollary is also true. When shaping is done less well, teams have unclear boundaries and so they can work less autonomously because they will run into trouble during the cycle. As a result, PM's need to spend more time on management and can spend less time on proper shaping. Which results in lower team autonomy.
Recap
In this article, I identified the 15 core patterns in Shapeup and mapped the relationships between them. This map helps to implement Shapeup and it shows how almost all of Shapeup's patterns revolve around creating team autonomy within the bounds of a shaped pitch. This creates a virtuous cycle, where we increasingly get more time for shaping and research on the one hand, and autonomy on the other. You can get this virtuous circle going by applying the tools offered in Shapeup.
Where will you begin?