Book Notes: Shape Up: Stop Running in Circles and Ship Work that Matters

 As part of improving our delivery process, I decided to read the book Shape Up: Stop Running in Circles and Ship Work that Matters. This post is a collection of notes from this book. 

Who is this book for?

This book is for product development teams who want to learn new way to think about shipping a product. It teaches you techniques and tools to define focused projects, address unknowns, and increase collaboration and engagement within the team.

Usual Disclaimer

This post is by no means a summary of the book, the notes mentioned here are extracts from the book. If you find these interesting, please pickup a copy of the book and give it a go.

Book Notes

Introduction

As software teams start to grow, some common struggles appear:

• Team members feel like projects go on and on, with no end in sight.
• Product managers can’t find time to think strategically about the product.
• Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”

Six-week cycles

Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The teams that run the six-week cycles are called the cycle teams.

Shaping the work

A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects 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.

Instead of asking how much time it will take to do some work, ask: How much time do we want to spend?

Making teams responsible

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

Targeting risk

At every step of the process, target a specific risk: the risk of not shipping on time. You can have the best strategy in the world, but if you can’t act on it, what good does it do?

• In the shaping process, reduce the risk by solving open questions before committing the project to a time box.
• In the planning process, reduce the risk by capping the bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first.
• In the building process, reduce the risk by integrating design and programming early. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible.

Principles of Shaping

We need to Shape the work at the right level of abstraction: not too vague and not too concrete.

When design leaders go straight to wireframes or high-fidelity mockups, they define too much detail too early. This leaves designers no room for creativity.

On the other end of the spectrum, projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means.

Properties of shaped work are:

• It's Rough: 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.
• It's Solved: All the main elements of the solution are there at the macro level and they connect together
• It's Bounded: Shaped work indicates what not to do. It tells the team where to stop. 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. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another.

You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle.

Here are the steps for shaping:

• Set boundaries: First we figure out how much time the raw idea is worth and how to define the problem. 
• Rough out the elements: Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast. 
• Address risks and rabbit holes: Take a hard look at the solution to find holes or unanswered questions that could trip up the team. Amend the solution, cut things out of it or specify details at certain tricky spots 
• Write the pitch: Package the whole thing with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. 

Set Boundaries

The first step of shaping is setting boundaries on what we’re trying to do. Sometimes an idea gets us excited right away. In that case we need to temper the excitement by checking whether this is really something we’re going to be able to invest time in or not. Other ideas are less exciting and feel more like a challenge we didn’t ask for. 

It helps to explicitly define how much of our time and attention the subject deserves. 

• Is this something worth a quick fix if we can manage?
• Is it a big idea worth an entire cycle? 
• Would we redesign what we already have to accommodate it? 
• Will we only consider it if we can implement it as a minor tweak?

This is called the appetite. Appetite can be thought of as a time budget for a standard team size.

An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. This principle, called “fixed time, variable scope,” is key to successfully defining and shipping projects. 

It’s too early to say “yes” or “no” on first contact. Even if we’re excited about it, we shouldn’t make a commitment that we don’t yet understand. In addition to setting the appetite, we usually need to narrow down our understanding of the problem.

When it comes to unclear ideas, the worst offenders are “redesigns” or “refactorings” that aren’t driven by a single problem or use case. When someone proposes something like “redesign the Files section,” that’s a grab-bag, not a project. It’s going to be very hard to figure out what it means, where it starts, and where it ends. Another sign of a grab-bag is the “2.0” label.

Find the Elements

Now that we have the constraints of an appetite and the problem we’re solving, it’s time to get from an idea in words to the elements of a software solution. Two things enable us to move at the right speed at this stage:

• We need to have the right people—or nobody—in the room. Either we’re working alone or with a trusted partner who can keep pace with us
• We need to avoid the wrong level of detail in the drawings and sketches.

The challenge here is to be concrete enough to make progress on a specific solution without getting dragged down into fine details 

Breadboarding

A breadboard is an electrical engineering prototype that has all the components and wiring of a real device but no industrial design. We can sketch and discuss the key components and connections of an interface idea without specifying a particular visual design.

• Places: These are things you can navigate to, like screens, dialogs, or menus that pop up. 

• Affordances: These are things the user can act on, like buttons and fields.

• Connection lines: These show how the affordances take the user from place to place.

Fat marker sketches

Sometimes the idea we have in mind is a visual one. In those cases Fat marker sketches come in handy. A fat marker sketch is a sketch made with such broad strokes that adding detail is difficult or impossible. 

This list of elements is extremely narrow and specific. It is exactly the kind of narrowing we hope to accomplish through the shaping process. 

Working at the right “level of abstraction” not only ensures we move at the right speed, it also leaves this important room for creativity in the later stages. 

What we’ve done is landed on an approach for how to solve the problem. But there may be some significant unknowns or things we need to address before we’d consider this safe to hand off to a team to build successfully. 

Also keep in mind that, at this stage, we could walk away from the project. We haven’t bet on it. 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.

Risks and Rabbit Holes

We’re shaping work for a fixed time window. We may trust from our experience that the elements we fleshed out in the previous chapter are buildable within the appetite (six weeks). But we need to look closer, because all it takes is one hole in the concept to derail that. 

In this step, we slow down and look critically at what we came up with.  

• Did we miss anything? 
• Are we making technical assumptions that aren’t fair?
• Does this require new technical work we’ve never done before?
• Are we making assumptions about how the parts fit together?
• Are we assuming a design solution exists that we couldn’t come up with ourselves?
• Is there a hard decision we should settle in advance so it doesn’t trip up the team? 

It is a good idea to call out any cases you specifically aren’t supporting to keep the project well within the appetite. There may be parts of the solution we got excited about during the sketching phase that aren’t really necessary. 

Before you’re ready to write up the idea to share more widely, you might need input on some parts of the concept you aren’t completely sure about. There may be a technical assumption that you need to verify with someone who understands the code better. This is a good time to grab some technical experts and walk them through the idea.  

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?” 

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. We’ve gone from a roughly formed solution with potential risk in it to a solid idea that we now hope to bet on in the future.

Write the Pitch

The purpose of the pitch is to present a good potential bet. It’s basically a presentation. The ingredients are all the things that we need to both capture the work done so far and present it in a form that will enable the people who schedule projects to make an informed bet. 

A good pitch will have the following 5 ingredients:

• Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this
• Appetite — How much time we want to spend and how that constrains the solution
• Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
• Rabbit holes — Details about the solution worth calling out to avoid problems
• 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 

Bets, Not Backlogs

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. Before each six-week cycle, 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. If it's decided to bet on a pitch, it goes into the next cycle to build. If not, then it's let go. There’s nothing to track or hold on to.

Six-week cycles

We wanted a cycle that would be long enough to finish a whole project, start to end. At the same time, cycles need to be short enough to see the end from the beginning. People need to feel the deadline looming in order to make tradeoffs. If the deadline is too distant and abstract at the start, teams will naturally wander and use time inefficiently until the deadline starts to get closer and feel real. After each six-week cycle, we schedule two weeks for cool-down.

The Betting Table

The betting table is a meeting held during cool-down where stakeholders decide what to do in the next cycle. The output of the call is a cycle plan. Buy-in from the very top is essential to making the cycles turn properly. The meeting is short, the options well-shaped, and the headcount low.  

If we bet six weeks, then we commit to giving the team the entire six weeks to work exclusively on that thing with no interruptions. 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.

The cool-down period between cycles can be used to fix bugs.  If a bug is too big to fix during cool-down, it can compete for resources at the betting table. 

Place Your Bets

When we add features to an existing product, we follow the standard Shape Up process: shape the work, bet on it, and give it to a team to build. 

New products are different. Whereas adding to an existing product is like buying a couch for a room with fixed dimensions, new product development is like figuring out where the walls and the foundation should go so the building will stand

In the R&D Mode, instead of betting on a well-shaped pitch, we mainly bet the time on spiking some key pieces of the new product idea. The shaping is much fuzzier because we expect to learn by building. Rather than delegating to a separate build team, senior people will make up the team. The aim is to spike, not to ship.

Next comes the production mode, where we work in formal cycles with clear-cut shaping, betting, and building phases.

In the final phase before launching the new product, we throw all structure out the window. It's called the clean-up mode. There’s something about putting your finger near the launch button that makes your hair stand up. That’s why we need to reserve some capacity at the end for the unexpected. In cleanup mode.

Some questions that you might hear on the betting table:

• Does the problem matter? 
• Is the appetite right? 
• Is the solution attractive?
• Is this the right time? 
• Are the right people available?

After the bets are made, someone from the betting table will write a message that tells everyone which projects we’re betting on for the next cycle and who will be working on them.

Hand Over Responsibility

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. The team is going to define their own tasks and their own approach to the work. They will have full autonomy and use their judgement to execute the pitch as best as they can 

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.

Work in the first few days doesn’t look like “work.” No one is checking off tasks. Nothing is getting deployed. There aren’t any deliverables to look at.  Why? Because each person has their head down trying to figure out how the existing system works and which starting point is best 

An important difference between tasks we think we need to do at the start of a project and the tasks we discover we need to do in the course of doing real work. 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

Getting One Piece Done

If the team completes a lot of tasks but there’s no “one thing” to click on and try out, it’s hard to feel progress.  Lots of things are done but nothing is really done. Instead they should aim to make something tangible and demoable early—in the first week or so.

Here are three criteria to think about when choosing what to build first:

• It should be core.  
• It should be small 
• It should be novel 

Map The Scopes

When asked to organize tasks for a project, people often separate work by person or role. This leads to people will completing tasks, but the tasks won’t add up to a finished part of the project early enough. Instead, they should create lists based on the structure of the project. 

In product development, the categories aren’t pre-cut for us. We usually build things we’ve never built before. We break the overall scope (singular) of the project into separate scopes (plural) that can be finished independently of each other.

As the team starts doing real work on the project they learn how the tasks are related and what the structure of the project is really like. Then they become able to factor the project into scopes. This is like dividing the map of the project into separate territories. The scopes reflect the meaningful parts of the problem that can be completed independently and in a short period of time—a few days or less. They are bigger than tasks but much smaller than the overall project.

Well-made scopes show the anatomy of the project. Every project has a natural anatomy that arises from the design you want, the system you’re working within, and the interdependencies of the problems you have to solve. 

New tasks constantly come up as you get deeper into a problem. A good way to deal with all those improvements is to record them as tasks on the scope but mark them with a ~ in front. This allows everyone on the team to constantly sort out the must-haves from the nice-to-haves 

Show Progress

Good-hearted managers don’t like asking for status. Managers would rather be able to see the status themselves when- ever they need to. In our naive notion of a list that’s planned up-front, somebody popu- lates 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.

Estimates don't show uncertainty. To see the status of the project without counting tasks and without numerical estimates we need to shift the focus from what’s done or not done to what’s unknown and what’s solved.

Work is like a hill

Every piece of work has two phases. First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution. 

The scopes give us the language for the project (“Locate,” “Reply”) and the hill describes the status of each scope (“uphill,” “downhill”). To see the status of the scopes, we can plot each one as a different color on the hill.

Nobody wants to raise their hand to management and say “I don’t know how to solve this problem.” This causes teams to hide uncertainty and accumulate risk. The hill chart allows everybody to see that somebody might be stuck without them actually saying it. A dot that doesn’t move is effectively a raised hand: “Something might be wrong here.”

It’s good to think of the uphill to be divided into three parts: 

• I’ve thought about this
• I’ve validated my approach
• I’m far enough with what I’ve built that I don’t believe there are other unknowns.

Some scopes are riskier than others. It’s better to get a few critical scopes over the top early in the project and leave the screw-tightening for later.

Decide When To Stop

Shipping on time means shipping something imperfect. There’s always some queasiness in the stomach as you look at your work and ask yourself: Is it good enough? Is this ready to release? 

Instead of comparing up against the ideal, compare down to baseline—the current reality for customers. How do customers solve this problem today, without this feature? What’s the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn’t work or wait for a solution because we aren’t sure if design A might be better than design B? 

Seeing that our work so far is better than the current alternatives makes us feel better about the progress we’ve made. This motivates us to make calls on the things that are slowing us down.

Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers. Rather than trying to stop scope from growing, give teams the tools, authority, and responsibility to constantly cut it down.

As we come up with things to fix, add, improve, or redesign during a project, we ask ourselves:

• 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 condition 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? 

Move On

It’s important to stay cool and avoid knee-jerk reactions. Give it a few days and allow it to die down. Be firm and remember why you made the change in the first place and who the change is helping. 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. 

Conclusion

I loved reading this book. It gives a different way of thinking about how to build and ship things. I am going to try to implement learnings from this book to actual projects. It's a must read for people who want to improve their building and shipping processes.