Book notes: “Shape Up” by Basecamp
There’s a specific appetite — the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.
Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work.
We use the appetite as a creative constraint on the design process.
The amount of time we set for our appetite is going to lead us to different solutions.
Our default response to any idea that comes up should be: “Interesting. Maybe someday.” In other words, a very soft “no” that leaves all our options open. If we always say “yes” to incoming requests we’ll end up with a giant pile of work that only grows.
Actionable: don’t put ideas or feature requests in the backlog. Add it somewhere else which makes it clear that we still need to dig deeper before committing it to be built.
In that case we flip from asking “What could we build?” to “What’s really going wrong?” Sure, a calendar sounds nice. But what is driving the request? At what point specifically does someone’s current workflow break down without this thing they’re asking for?
When it comes to unclear ideas, the worst offenders are “redesigns” or “refactorings” that aren’t driven by a single problem or use case. A tell-tale sign of a grab-bag is the “2.0” label. We made the mistake in the past of kicking off a “Files 2.0” project without really considering what that meant.
We haven’t made any commitments or promises about it. What we’ve done is added value to the raw idea by making it more actionable. We’ve gotten closer to a good option that we can later lobby for when it’s time to allocate resources.
Beware the simple question: “Is this possible?” In software, everything is possible but nothing is free. We want to find out if it’s possible within the appetite we’re shaping for. Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?” That’s a very different question.
It sounds like an obvious point but it’s surprising how often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing.
Backlogs are a big weight we don’t need to carry. Dozens and eventually hundreds of tasks pile up that we all know we’ll never have time for. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.
Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.
It’s easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles. Really important ideas will come back to you.
Some companies use two-week cycles (aka “sprints”). We learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead. The amount of work you get out of two weeks isn’t worth the collective hours around the table to “sprint plan” or the opportunity cost of breaking everyone’s momentum to re-group.
After years of experimentation we arrived at six weeks. Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning.
The end of a cycle is the worst time to meet and plan because everybody is too busy finishing projects and making last-minute decisions in order to ship on time.
Therefore, after each six-week cycle, we schedule two weeks for cool-down.
We talk about “betting” instead of planning because it sets different expectations.
It’s not really a bet if we say we’re dedicating six weeks but then allow a team to get pulled away to work on something else. When people ask for “just a few hours” or “just one day,” don’t be fooled. Momentum and progress are second-order things, like growth or acceleration. Losing the wrong hour can kill a day. Losing a day can kill a week.
Finally, the circuit breaker motivates teams to take more ownership over their projects. As we’ll see in the next chapter, teams are given full responsibility for executing projects. That includes making trade-offs about implementation details and choosing where to cut scope. You can’t ship without making hard decisions about where to stop, what to compromise, and what to leave out. A hard deadline and the chance of not shipping motivates the team to regularly question how their design and implementation decisions are affecting the scope.
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.
Done means deployed
testing and QA needs to happen within the cycle.
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.
Teams discover tasks by doing real work. For example, the designer adds a new button on the desktop interface but then notices there’s no obvious place for it on the mobile webview version.
what to build first:
- it should be core
- it should be small
- it should be novel
This goes back to the notion of imagined versus discovered tasks. In our naive notion of a list that’s planned up-front, somebody populates it with items that are gradually checked off. In real life, issues are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress.
Some teams struggle with backsliding when they first try the hill chart. They consider a scope solved, move it to the top of the hill, and later have to slide it back when they uncover an unexpected unknown.
When this happens, it’s often because somebody did the uphill work with their head instead of their hands. Coming up with an approach in your head is just the first step uphill. We often have a theory of how we’ll solve something — “I’ll just use that API” — and then the reality turns out to be more complicated. It’s good to think of the first third uphill as “I’ve thought about this,” the second third as “I’ve validated my approach,” and the final third to the top as “I’m far enough with what I’ve built that I don’t believe there are other unknowns.”
Variable scope is not about sacrificing quality. We are extremely picky about the quality of our code, our visual design, the copy in our interfaces, and the performance of our interactions. The trick is asking ourselves which things actually matter, which things move the needle, and which things make a difference for the core use cases we’re trying to solve.
• Is this a “must-have” for the new feature?
• Could we ship without this?
• What happens if we don’t do this?
• Is this a new problem or a pre-existing one that customers already live with?
• How likely is this case or condition to occur?
• When this case occurs, which customers see it? Is it core — used by everyone — or more of an edge case?
• What’s the actual impact of this case or con- dition in the event it does happen?
• When something doesn’t work well for a particular use case, how aligned is that use case with our intended audience?
Summing up
• Shaped versus unshaped work
• Setting appetites instead of estimates
• Designing at the right level of abstraction
• Concepting with breadboards and fat marker sketches
• Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
• Choosing the right cycle length (six weeks)
• A cool-down period between cycles
• Breaking projects apart into scopes
• Downhill versus uphill work and com- municating about unknowns
• Scope hammering to separate must-haves from nice-to-haves
Work has to come from somewhere, and it takes work to figure out what the right work is. This is shaping.
…a tiny team can throw out most of the structure. You don’t need to work six weeks at a time. You don’t need a cool- down period, formal pitches or a betting table. Instead of parallel tracks with dedicated shapers and builders, the same people can alternate back and forth. Be deliberate about which hat you’re wearing and what phase you’re in. Set an appetite, shape what to do next, build it, then shape the next thing. Your bets might be different sizes each time: maybe two weeks here, three weeks there. You’re still shaping, betting, and building, but you’re doing it more fluidly without the rigid structure of cycles and cool-downs.
