DEV Community

Cover image for Book notes: Shape Up: Stop Running in Circles and Ship Work that Matters.
Dan Lebrero
Dan Lebrero

Posted on • Originally published at danlebrero.com on <time datetime="2021-08-08T09:51:31Z" class="date-no-year">Aug 8</time>

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

These are my notes on Shape Up: Stop Running in Circles and Ship Work that Matters by Ryan Singer.

Ryan explains Basecamp's product development process. In a nutshell: shape up bets + pick up a bet + let the team alone for six weeks to build it.

The book has no fluff, it is direct and to the point.

You can read it for free at https://basecamp.com/shapeup, plus you can find there some good extra content.

Key Insights

sketches

  • Shape:
    • Right level of abstraction.
    • Wireframes too concrete.
    • Words too abstract.
    • Properties: rough, solved, bounded.
  • Estimate: start with a design, end with a number.
  • Appetite:
    • Start with a number, end with a design.
    • A creative constraint on the design.
    • Without time limit, there is always a better version.
  • In software everything is possible but nothing is free.
  • Some kinds of trade-offs are difficult to make when working inside the cycle under pressure.
  • Backlogs: growing pile that gives us the feeling of always being behind.
  • Important ideas will come back.
  • Bet:
    • Are commitments to uninterrupted time. No even for bugs.
  • Hill chart: hill chart
  • Good enough: Instead of comparing against the ideal solution, compare against the current state:
    • Changes perspective from "never good enough" to "better than what the customer has right now"
  • Cutting scope:
    • Makes the product better at some things instead of others.
    • It differentiates your product from others.

TOC

Chapter 1 - Introduction

  • Growing pains:
    • Team feels projects have no end.
    • Product managers can't find time to think strategically about the product.
    • Founders wonder why features take way longer than in early days.

Part 1: Shaping

Chapter 2 - Principles of Shaping

  • Shape:
    • Right level of abstraction.
    • Wireframes too concrete.
    • Words too abstract.
    • Properties:
      • It is rough.
      • It is solved:
        • Though through.
        • Should have no rabbit holes or open questions.
      • It is bounded:
        • What not to do.
        • When to stop.
        • Time bounded.
  • Who shapes:
    • Sharping requires:
      • Interface ideas (designer) +
      • Technical possibilities (technical literate) +
      • Business priorities.
    • One generalist or two specialist.
  • Steps:
    1. Set Boundaries.
    2. Rough out elements.
    3. Address risks and rabbit holes.
    4. Write pitch.

Chapter 3 - Set Boundaries

  • Set appetite, either:
    • Small batch: 1 designer + 1/2 programmers for 1-2 weeks.
    • Big batch: same but 6 weeks.
  • Estimate: start with a design, end with a number.
  • Appetite: start with a number, end with a design.
  • Appetite: a creative constraint on the design.
    • Fixed time, variable scope.
    • Without time limit, there is always a better version.
  • The best solution is relative to your constraints.
  • Default answer to raw ideas: Interesting, maybe some day.
  • Narrow down the understanding of the problem.

Chapter 4 - Find the Elements

  • Questions 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?
  • Fast moving exploratory process.
    • More breath than deep.
  • 2 prototype techniques:
    • Breadboarding:
      • 3 elements:
        1. Places.
        2. Affordances:
          • Includes information to show.
        3. Connection lines:
          • How affordances take from place to place.
      • Only words, no pictures. breadboarding
    • Fat market sketches:
      • When idea is visual one.
      • Sketch made with such broad strokes that adding details is difficult of impossible.

sketches

Chapter 5 - Risks and Rabbit Holes

  • Slow down and analyze the solution.
  • Some kinds of trade-offs are difficult to make when working inside the cycle under pressure.
  • Specify what is out of scope.
  • Lastly, present to technical experts:
    • Check your assumptions, get more info.
    • Help finding risks.
    • Do not create a doc or slideshow but walk them in a whiteboard.
  • In software everything is possible but nothing is free.

Chapter 6 - Write the Pitch

  • Put the concept in a form that other people will be able to understand, digest and respond to.
  • 5 parts:
    1. Problem:
      • Best problem definition consist of a single specific story that show why the status quo doesn't work.
    2. Appetite:
      • Part of the problem definition.
      • It takes work and design insight to get to a single idea that fits in a small time box.
    3. Solution:
      • More detail than fat markers, but less than wireframes.
      • Embedded sketches.
      • Annotated fat markers.
    4. Rabbit holes.
    5. No Gos.

Part 2: Betting

Chapter 7 - Bets, Not Backlogs

  • Backlogs: growing pile that gives us the feeling of always being behind.
  • Every six-week cycle, look at pitches from the last 6 weeks, plus others purposefully revived.
  • No central backlog. Everybody can track their ideas as they please.
  • Ideas are cheap.
  • Important ideas will come back.
  • To ease planning:
    • Standard time box.
    • Standard teams:
      • 1 designer, 2 programmers, 1 part time QA.
    • Standard type of project.

Chapter 8 - The Betting Table

  • Betting table:
    • CEO, CTO, senior programmer, product strategist.
    • They plan for next cycle.
    • 1-2 hours meeting.
    • Nobody can change the plan afterwards.
  • Bet:
    • Have a payout.
    • Are commitments to uninterrupted time:
      • No even for bugs:
        • Wait for cooldown period.
        • For bigger issues, create a pitch.
        • "Bug smash" time around holidays, as it is hard to plan anything.
    • Cap losses:
      • By default, bets are not extended:
        • Need to be reshaped and repitched.
      • Motivates the team to take ownership.

Chapter 9 - Place Your Bets

  • In existing products, process is as described.
  • In new product, 3 phases:
    1. R&D:
      • No pitch, bet on spiking product idea.
      • Team is senior people:
        • CTO, CEO, senior designed.
        • You cannot delegate when you dont know yourself what you want.
        • Loads of architecture-like decisions.
      • Several cycles.
    2. Production mode:
      • Shaping process as described.
      • Still not shipped to customers but merged to main.
    3. Clean up mode:
      • 1-2 cycles of "bug smashing" and polishing.
      • No team, "everybody".
      • Unstructured but disciplined.
  • Questions when choosing bets:
    • Does the problem matter?
    • Is the appetite right?
    • Is the solution attractive?
    • Is this the right time?
    • Are the right people available?
      • Each cycle they create teams around the projects.

Part 3: Building

Chapter 10 - Hand Over Responsibility

  • Assign projects, not tasks.
  • Done == deployed.
  • Expect radio silence up to 3 days when a project starts:
    • If more than 3 days, then step in to see what is going on.

Chapter 11 - Get One Piece Done

  • One vertical slice at a time.
  • First make it work, then make it beautiful.
  • Build first, what is:
    • Core.
    • Small.
    • Novel.

Chapter 12 - Map the Scopes

  • Split the project into slices that can be implemented/finished independently (scopes).
  • Report progress on scopes, not individual tasks.
  • Scopes are discovered by doing real work.

Chapter 13 - Show Progress

  • Hill chart: hill chart
  • One dot per scope.
  • Historical hill chart allows to easily see what scopes are stuck.
  • Uphill area:
    1. First third: "I've thought about this"
    2. Second third: "I've validated my approach"
    3. Last third: "I'm far enough with what I've built that I don't believe that are other unknowns"

Chapter 14 - Decide When to Stop

  • Shipping on time means shipping something imperfect.
  • Good enough: Instead of comparing against the ideal solution, compare against the current state:
    • Changes perspective from "never good enough" to "better than what the customer has right now"
  • Cutting scope:
    • Makes the product better at some things instead of others.
    • It differentiates your product from others.
  • QA:
    • 1 person on a team of 12.
    • Find edge cases.
    • All issues found are by default "nice-to-have".
    • Implementing team decides which ones to fix.

Chapter 15 - Move On

  • Take any customer feedback easy.

Discussion (0)