I recently read the Shape Up book written by Ryan Singer of the BaseCamp team. It has a delightful subtitle – “Stop Running in Circles and Ship Work that Matters” – and is full of insightful commentary on software development.
The core principle in Shape Up is “shaping” which includes multiple steps of exploration and understanding with the central goal of eliminating risk at each step.
There are three key insights I take away from this book:
- 6 week iteration with 2 week cooldown (not traditional sprints)
- No shared backlog
- Focus on “how much do I want to invest in X” vs “how long will X take”
These insights combine to both reduce project risk and to increase team focus thus enabling delivery of high quality software. Let’s dive into each insight a bit.
Insight 1: 6 week iteration / 2 week cooldown
Central to the Shape Up philosophy is to understand and define work such that it can be implemented in a 6 week iteration. “Shaping” includes exploring risks, dependencies, and scoping to reduce unknowns and increase the probability of shipping on time.
The key problem with estimation done too early is that some tasks may overrun their estimates by 2x, 3x, or more. Shaping reduces the opportunities for 2x/3x overruns – work may not be planned until it has been both shaped (reducing unknowns) and reviewed (ensuring quality shaping).
Furthermore the 6 week iteration works as a circuit breaker. If work is not completed in 6 weeks it is by default removed from plan as it is deemed too risky and too unknown (this can be reviewed). This prevents the team from losing weeks or months due to rabbit holes.
Every story/capability implemented in the Shape Up philosophy is presented as a “bet” (this is work worth doing) and teams accept work based on their “appetite” (we are willing to spend up to six weeks on this week).
Using shaping, bets, and appetite forces clear scoping and removal of unknowns. Estimates may still not be perfect but the error bar is much smaller. The process includes a 2 week “cooldown” between iterations for planning the next iteration and minor technical debt cleanup (such as implementing completely understood small leftover tasks). This also enforces that a team cannot continuously “sprint”.
Insight 2: No shared backlog
This was one of my favorite parts of the book. The philosophy behind no shared backlog is that the cost of maintaining and grooming a shared backlog takes more effort than it’s worth. If work is not high enough priority for the next iteration it rarely gets done, especially because new requirements come in as software is used further.
This does not mean that each story/capability/bet only gets one shot at being implemented. Rather, the individual(s) proposing the work simply pitches that work again at the next planning cycle. Individual can keep their own backlog of tasks they want down but the team is not weighed down with this shared backlog.
I like this because it increases the shared focus of the team and keeps any work-to-do as fresh as possible. (Don’t you hate looking at a 12 month old task and wondering why am I supposed to do this?)
Further, by considering each story/capability as a “bet” you have an implicit reminder that it may not work out and that it may be too risky/costly to spend time on. This is more useful than a “check all the boxes” philosophy.
Insight 3: Appetite vs “how long” focus
This philosophy flips the estimation focus on its head. “How long” a task will take varies greatly depending on how you do it – for a given task there may be ways to implement it in 2 days, 2 weeks, and 2 months (maybe even 2 years). Worse estimation is often used so we can build a Tetris-like sprint plan, committing to as much work as possible with the given team, despite the fluctuations possible due to unknowns.
This also increases focus on quickly delivering value to users. When a team asks themselves what is their appetite for a given story they may find they are willing to spend 2 weeks on it but not 6. Are the users better off with the reduced-scope 2-week version or not having any capability at all? This depends, but you can at least be honest about the tradeoff!
Lastly thinking about appetite is a reminder to think about when to stop. The author states “Scope grows like grass” and any software developer surely has experience with that!
Concluding remarks
The Shape Up book is densely packed with insights. Whether you adopt some or all of their practices you will improve your software development process. There is plenty of room for risk reduction and informed scoping in any project.
