Shape Up

2020-11-16

“Shape Up: Stop Running in Circles and Ship Work that Matters” by Ryan Singer

My Summary

Shape Up is Basecamp’s product development methodology. It is an alternative to methodologies that are steeped in the following problems:

• Developers and product teams that are burnt-out
• Stagnant products that aren’t delivering regular customer value
• Bloated teams and development processes
• Crippling backlogs

Shape Up’s alternative approach is well-summarized in the foreword:

For one, we’re not into waterfall or agile or scrum. For two, we don’t line walls with Post-it notes. For three, we don’t do daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking, none of that.

Chapter 1: Introduction

• Shape Up uses repeating 6-week cycles w/ 2-week cool down periods between cycles - cool-down periods have no scheduled work - for creators, they can be used for bug fixes, paying tech debt, explore ideas, etc - for others, they could be used to consider what comes next, generate some new ideas, etc
• no daily meetings; no continual management of a backlog
• projects are shaped before they are given to a team
• projects are shaped based on appetite — how much time to we want to spend on this? how much is this idea worth?
• full responsibility is given to the assigned team; they…
  • define their own tasks
  • make their own adjustments to scope
  • build vertical slices (scopes) of a product one-at-a-time
• ^ in other words, this is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers
• project are not given to a team until all rabbit holes and interdependencies have been traced
• if a project runs over 6 weeks, it doesn’t get an extension by default; instead it would have to be betted upon again

Chapter 2: Principles of Shaping

• projects are shaped as “not too abstract” and “not too specific”, but just right
  • wireframes are too concrete
  • words-only are too abstract
  • aim for napkin sketches that have all the pieces represented, but leave out low-level details; could use fat-marker sketches for this
• two tracks, during any 6-week cycle…
  • there are teams building work that’s been previously shaped
  • there are shapers working on what the teams might potentially build in a future cycle
• work on the shaping is kept private and not shared with the wider team until the commitment has been made to bet on it
• steps for shaping
  • set boundaries: determine how much time the raw idea is worth and define the problem
  • rough out the elements: sketch the solution
  • address risks and rabbit holes
  • write the pitch!

Chapter 3: Set Boundaries

• set the appetite — small batch (2 weeks) or big batch (6 weeks)
  • 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?
• appetites fix the time, but allow for scope and design to be variable within that scope (like telling an artist you only get these 3 colors, go!)
• without a time-limit, there’s always a better solution; using a time-bound appetite forces the teams to make decisions and trade-offs and get something done
• we don’t put raw ideas on a backlog, instead we can come back to it later and see if the raw idea can be shaped into a pitch that gets bet upon
  • generally speaking, avoiding making some big backlog — you want to approach each shaping cycle with fresh eyes
• flip from asking “What could we build?” to “What’s really going wrong?” when trying to understand an idea/problem
• avoid shaping ideas framed as “grab bags” or “redesigned”; keep digging to determine exactly why or what is prompting the idea in the first place
  • example: “redesign the Files section” becomes “We need to rethink the Files section because sharing multiple files takes too many steps”
  • ^ this provides a much better starting point and creates better questions:
    • are all the steps necessary?
    • which steps are taking up the most time?
    • etc

Chapter 4: Find the Elements

• in this step, you’re moving from an idea (in words) to the elements of a software solution
• use the right fidelity and the right group
  • two people sitting at a diner table making a napkin, fat-marker sketch
  • can use techniques like “breadboarding”, flow charts, or even fat-market UI sketches
• try to answer
  • where in the current system does the new thing fit?
  • how do you get to it?
  • what are the key components or interactions?
  • where does it take you?
• the elements produced should be specific enough to better refine the idea, but not so specific that a designer couldn’t come alongside later and do what they do best
• at the end of this stage, you have the napkin or the white-board sketch, etc but it is still very much in your private sphere, decipherable by you and perhaps a partner who helped you shape it
• note: at this point, we’re also free to walk away from this idea — we haven’t bet on it yet

Chapter 5: Risks and Rabbit Holes

• looking to ensure that the shaped idea and elements could fit with the appetite
• questions to ask
  • 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?
• note any parts of the problem that are “out of bounds” and don’t need to be solved within the scoped project
• cut back your tendency to throw lots of extra things into the shaped project; just stick with the core stuff for now; nice-to-haves can be approach/scoped later
• towards the end of this step, it is a good time to bring in an expert or two to weigh-in on the idea
  • ^ DON’T ASK “is it possible to do X?”
  • ^ ASK “is X possible in 6-weeks?”
• ^ do this on a whiteboard, not some polished slideshow; recreate the proposal as a slightly more well-prepared napkin sketch

Chapter 6: Write the Pitch

• five sections of a pitch
  • problem — the raw idea, a use case, or something we’ve seen that motivates us to work on this
    • heavily focus on establishing the problem here before you say anything about the proposed solution (that comes later in the pitch)
    • this problem gives a baseline for comparison later
    • can be shown as embedded videos, sketches, screenshots, w/ data, etc
  • 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
    • these can be fat-market sketches with extra annotation, whatever the case, it needs to be easily understood
    • note: people who read the pitch and look at the drawings without much context need to “get” the idea
  • 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
• post the pitches somewhere the folks on the betting table can see it and read/ask questions asynchronously; nobody should be saying yes/no at this point, just asking questions and getting clarification

Chapter 7: Bets, Not Backlogs

• Shape Up has no backlogs — they have the betting table, and it contains a few quality pitches each betting session
• Each time a betting session is over, you’ll have some betted-upon projects and then pitches that can be archived
• Pitches that are archived can still be followed, re-pitched, but REMEMBER any pitch that is brought back must be be brought back with a context, by a person, with a purpose; everything is relevant, timely, and of the moment; don’t worry the important ideas will come back if they are that important

Chapter 8: The Betting Table

• at this point, bets are placed on shaped projects at “the betting table”
• the betting table is a meeting held during cool-down where stakeholders decide what to do in the next cycle
  • at Basecamp, the table consists of the CEO (who in our case is the last word on product), CTO, a senior programmer, and a product strategist
  • there is no “second step” after this
• projects that are bet upon are assigned to a team
  • Basecamp’s project teams consist of either one designer and two programmers or one designer and one programmer
  • they’re joined by a QA person who does integration testing later in the cycle
• once something it is bet upon, teams are NOT INTERRUPTED!
• how to deal with bugs?
  • strategy 1: do them during the cool down
  • strategy 2: if it is big enough, make a pitch for it and put it on the betting table
  • strategy 3: do a special “bug smash” cycle, maybe during the holiday season
• the output of this process is the cycle plan
• after the betting is done, wipe the slate clean when the next betting session arises

Chapter 9: Place Your Bets

• in weighing pitches, we are weighing a few things
  • which problems are more important to work on than others?
  • is our appetite for solving a problem convincing enough to spend a cycle on it?
    • is the timing right?
    • is the amount of time right?
    • do we have the right people/team to execute this?
• design shouldn’t happen at the betting table
• when we pick a pitch, we are also picking the team who will work on it
  • at Basecamp, those at the betting table are picking the teams
  • at some other companies, after the bets are placed, then the core product folks pick which of the bets they want to work on (similar to how Valve does thing)
• once bets are placed, a message goes out to the team!

Chapter 10: Hand Over Responsibility

• the team who is working on a bet is free to task themselves how they see fit
• the team has autonomy on how they want to accomplish the task, but remember, the task has been set, the boundaries have been defined
• any QA and testing needs to happen within the cycle
• help documentation, marketing, announcements don’t strictly have to be done within the cycle
• when a cycle starts, give the team room to breath as they figure out how to start

Chapter 11: Get One Piece Done

• instead of trying to scaffold “the whole front-end” or “the whole back-end” for a project, try to build end-to-end working pieces one at-a-time
• have a bias for building little MVPs (“slices/scope”) versus dangling work that isn’t fully integrated or testable/tangible
• programmers don’t need to wait — build out scaffolds, simple UIs, iterate with the designer, start with simple and leave the fancy details and styling for the end
• another way of stating: wire things up first (build the breadboard) and get it working, then the polish can come later
• “the point is to create a back-and-forth between design and programming on the same piece of the product… instead of one big hand-off”
• first, start with elements of the project that are CORE, small, and novel (get the snowball rolling and build momentum!)

Chapter 12: Map the Scopes

• when talking about progress, report on which “slices/scope” of the project are done
• scopes can be developed during a cycle as tasks fragment along lines of deliverable functionality
• scopes normally won’t arise until after a few days in a cycle
• well-made scopes:
  • you can see the whole project and nothing important that worries you is hidden down in the details
  • scopes give you the right language for talking about the project
  • when new tasks come up, you know where to put them; the scopes act like buckets that you can easily lob new tasks into
• poor scopes:
  • it’s hard to say how “done” a scope is
  • “grab bags”, “junk drawers”, “uncategorized lists of things”
  • if it’s too big to finish soon

Chapter 13: Show Progress

• instead of reporting on progress with tasks counts and numerical estimates, report it in terms of “what’s solved” and “what’s unknown”
• you can use scopes to organize the progress reports on a hill chart where the left side of the chart is “complete unknown” and the right side is “completely solved”; as the cycle progresses, the scopes can move around on the hill chart
• the hill chart allows everybody to see that somebody might be stuck without them actually saying it; hill charts can be viewed over time
• conversation becomes how do we get over the hill instead of about somebody dropping the ball, etc
• 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.”

Chapter 14: Deciding When to Stop

• compare work in the cycle to the current customer baseline, not to the “pie in the sky” ideal
• cutting scope isn’t lowering quality
• mark things as nice-to-have during a cycle with scope hammering by asking the following questions
  • 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?

Chapter 15: Move On

• stay cool after delivering and avoid knee jerk reactions
• don’t gather debt… for any feedback coming in, respond with a gentle “no” or “we might consider that in the future”
• raw ideas/feedback that are arriving are raw — they need to be shaped/considered/betted upon; a virtuous cycle

Appendix: Adjusting to Your Size

• once you become big enough to specializes, you can have 2 cycles happening in-sync with each other
  • a schedule for out-of-cycle folks (those not building, but strategically involved with the product)
    • 6 weeks for shaping
    • 2 weeks for betting
    • repeat
  • a schedule for in-cycle folks (those building)
    • 6 weeks for building
    • 2 weeks for cool down
    • repeat