Book summary: Shape Up

“Shape Up: Stop Running in Circles and Ship Work that Matters” is a book from Ryan Singer about how Basecamp do product development.

The following is mostly just copy & pastes of the parts I found most interesting. Typically, the more detailed the notes, the more useful I found the chapter. The original book itself though isn’t a difficult read (and it’s free online), so I recommend checking it out directly.

Introduction

Ch 1: Introduction

Growing pains

As software teams start to grow, struggles appear, such as projects dragging on, no time to think strategically, and features not shipping.

Basecamp dealt with this by switching from ad-hoc project lengths to repeating cycles, and formalizing our pitching and betting processes. This book is about those improvements.

Six-week cycles

We work in six-week cycles: long enough to build something and short enough that everyone can feel the deadline looming from the start.

Shaping the work

A small senior group works in parallel to the cycle teams, shaping the work first. Key elements of a solution are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.

When shaping, we ask: How much time do we want to spend? We narrow the problem and design the outline of a solution that fits within those time constraints.

Making teams responsible

We give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time.

Together, 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.

Targeting risk

At every step of the process we target the risk of not shipping on time. This book isn’t about the risk of building the wrong thing.

We reduce risk in the shaping process by solving open questions before we commit to a project.

We reduce risk in the planning process by capping our bets to six weeks.

We reduce risk in the building process by integrating design and programming early. We build one meaningful piece of the work end-to-end early on and then repeat.

Part 1: Shaping

Ch 2: Principles of Shaping

When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.

Wireframes can be too concrete; too much detail too early leaving designers no room for creativity.

On the other end of the spectrum, words can be too abstract. When a project is defined in a few words, nobody knows what it means, leaving team members with insufficient information to make trade-offs.

Instead, potential projects should be rough and unfinished, but has been thought through with a high level solution is spelled out. Work should also be bounded, so as to indicate what not to do.

This type of Shaping is primarily design work, ideally done by someone who is technically literate. Shaping has four main steps covered in the next four chapters…

 

Ch 3: Set Boundaries

The first step of shaping is setting boundaries on what we’re trying to do. Figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.

Ch 4: Find the Elements

Next comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. Consider using “fat marker” sketches, that leave enough room for designers in later phases. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out. Keep in mind that, at this stage, we could walk away from the project.

Ch 5: Risks and Rabbit Holes

Once we think we have a solution, remember that we’re shaping work for a fixed time window. Take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.

Before you’re ready to write up the idea to share more widely, get input from technical experts. Walk them through the idea. Instead of asking “Is this possible?” Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?”

At the end of this stage, we have the elements of the solution, patches for potential rabbit holes, and fences around areas we’ve declared out of bounds., ready to make the transition to presenting the idea at the betting table.

Ch 6: Write the Pitch

Package the elements of your solution up into a formal write-up. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations, and goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.

There are five ingredients that we always want to include in a pitch:

1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
2. Appetite — How much time we want to spend and how that constrains the solution
3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
4. Rabbit holes — Details about the solution worth calling out to avoid problems
5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable

For the pitch, consider asynchronous communication,  escalating to real-time only when necessary. This gives everyone the maximum amount of time under their own control to consider and contribute.

 

Part 2: Betting

Ch 7: Bets, Not Backlogs

Now that we’ve written a pitch, where does it go? It doesn’t go onto a backlog.

Backlogs are a big weight we don’t need to carry. 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.

The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from working on what really matters.

So what do we do instead? Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle. At the betting table, they look at pitches from the last six weeks — or any pitches that somebody purposefully revived and lobbied for again.

Nothing else is on the table. Everyone can still track pitches, bugs, requests, or things they want to do independently without a central backlog.

If the idea really is important, it will come back to you.

 

Ch 8: The Betting Table

Now that we have some good potential bets in the form of pitches, it’s time to make decisions about which projects to schedule.

Six-week cycles

Committing time and people is difficult if we can’t easily determine who’s available and for how long. Working in cycles helps. We found that two weeks is too short to get anything meaningful done and costly due to the planning overhead. Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning.

Cool-down

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: no scheduled work where we can breathe, meet, and think. The time can be used to fix bugs, explore new ideas, or try out new technical possibilities.

Team and project sizes

Our project teams consist of a designer, 1-2 programmers and a QA person.

The betting table

The betting table is a meeting held during cool-down where stakeholders decide what to do in the next cycle, from new pitches or possibly one or two older pitches. Remember that there is no backlog.
The output of the call is a cycle plan.

We talk about “betting” instead of planning because it sets different expectations. First, bets have a payout. The pitch defines a specific payout that makes the bet worth making. Second, bets are commitments. We commit to giving the team the entire six weeks to work exclusively on that thing with no interruptions. Third, a smart bet has a cap on the downside. The most we can lose is six weeks.

Uninterrupted time

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 you make a bet, you honor it. We do not allow the team to be interrupted or pulled away to do other things.

The circuit breaker

We combine this uninterrupted time with a tough but extremely powerful policy. Teams have to ship the work within the amount of time that we bet. If they don’t finish, by default the project doesn’t get an extension.

First, it eliminates the risk of runaway projects.
Second, if a project doesn’t finish in the six weeks, it means we did something wrong in the shaping. The circuit breaker pushes us to reframe the problem.
Finally, the circuit breaker motivates teams to take more ownership over their projects.

What about bugs?

There is nothing special about bugs that makes them automatically more important than anything else. All software has bugs. The question is: how severe are they? Crises are rare. The vast majority of bugs can wait six weeks or longer, and many don’t even need to be fixed.

That said, 3 strategies have worked for us.

• Use the cool-down period between cycles. 2 weeks every six weeks actually adds up to a lot of time for fixing them.
• Bring it to the betting table. If a bug is too big to fix during cool-down, it can compete for resources at the betting table.
• Periodically schedule a bug smash.

Keep the slate clean

The key to managing capacity is giving ourselves a clean slate with every cycle. That means only betting one cycle at a time and never carrying scraps of old work over without first shaping and considering them as a new potential bet.

Ch 9: Place Your Bets

Depending on whether we’re doing R&D, building a new product, improving an existing product, or doing cleanup, we’re going to set different expectations about what happens during the six-week cycle.

Here are some common questions you might hear when people at the betting table are debating which bets to place.

• Does the problem matter?
• Is the appetite right?
• Is the solution attractive?
• Is this the right time?
• Are the right people available?
• Post the kick-off message

Part 3: Building

Ch 10: Hand Over Responsibility

We don’t start by assigning tasks to anyone. Splitting the project into tasks up front is like putting the pitch through a paper shredder. Everybody just gets disconnected pieces. We want the project to stay “whole” through the entire process so we never lose sight of the bigger picture. Instead, we trust the team to take on the entire project and work within the boundaries of the pitch. Teams love being given more freedom to implement an idea the way they think is best.

Done means deployed

At the end of the cycle, the team will deploy their work. This constraint keeps us true to our bets and respects the circuit breaker. The project needs to be done within the time we budgeted; otherwise, our appetite and budget don’t mean anything. That also means any testing and QA needs to happen within the cycle.

Ch 11: Get One Piece Done

The team should aim to make something tangible and demoable early—in the first week or so. That requires integrating vertically on one small piece of the project instead of chipping away at the horizontal layers.

Ch 12: Map the Scopes

Organize by structure, not by person

When asked to organize tasks for a project, people often separate work by person or role: they’ll create a list for Designers and a list for Programmers. This leads to the problem we talked about in the previous chapter—people will complete tasks, but the tasks won’t add up to a finished part of the project early enough.

Ch 13: Show Progress

Good-hearted managers don’t like asking for status and would rather be able to see the status themselves whenever they need to.

Todo lists dont provide great insights since some tasks may not have been identified, and to-do lists actually grow as the team makes progress.

Estimates can also be useful, but don’t show uncertainty.

Ch 14: Decide When to Stop

There’s always more work than time. Shipping on time means shipping something imperfect. In can help to, instead of comparing up against the ideal, compare to the current reality for customers. Seeing that our work so far is better than the current alternatives makes us feel better about the progress we’ve made. We can say “Okay, this isn’t perfect, but it definitely works and customers will feel like this is a big improvement for them.”

Time constraints can be very healthy and force the team to make trade-offs. When somebody says “wouldn’t it be better if…”, they should first ask themselves: Is there time for this? Without a deadline, they could easily delay the project for changes that don’t actually deserve the extra time.

We expect our teams to actively make trade-offs and question the scope instead of cramming and pushing to finish tasks. We create our own work for ourselves. We should question any new work that comes up before we accept it as necessary.

Scope grows naturally and every project is full of scope we don’t need. Rather than trying to stop scope from growing, give teams the tools, authority, and responsibility to constantly cut it down.

QA is for the edges

QA can limit their attention to edge cases because the designers and programmers take responsibility for the basic quality of their work. Programmers write their own tests, and the team works together to ensure the project does what it should according to what was shaped. This follows from giving the team responsibility for the whole project.

We think of QA as a level-up, not a gate or a check-point that all work must go through. We’re much better off with QA than without it. But we don’t depend on QA to ship quality features that work as they should.

We treat code review the same way. The team can ship without waiting for a code review. There’s no formal check-point. But code review makes things better, so if there’s time and it makes sense, someone senior may look at the code and give feedback. It’s more about taking advantage of a teaching opportunity than creating a step in our process that must happen every time.

Ch 15: Move On

Saying “no” to follow up feature requests doesn’t prevent you from continuing to contemplate them and maybe shape them up into future projects. Saying “yes,” on the other hand, takes away your freedom in the future. It’s like taking on debt.

Remember, the thing you just shipped was a six-week bet. If this part of the product needs more time, then it requires a new bet. Let the requests or bugs that just came up compete with everything else at the next betting table.

Conclusion

The Shape Up method presented in this book may take some thought and experimentation to pull out the right pieces and adapt them to your team.

The key concepts are:

• Shape work first
• Sett appetites instead of estimates
• Design at the right level of abstraction
• Concept with fat marker sketches
• Make bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
• Choose the right cycle length (six weeks?)
• Have a cool-down period between cycles
• Break projects apart into scopes
• Communicate about unknowns
• Hammer scope to separate must-haves from nice-to-haves

Tags: basecamp, planning, productmanagement, projectmanagement, shapeup, summary