Shape Up

Shape Up

Author

Ryan Singer

Year
2019
image

Review

Shape Up is an incredibly refreshing read. It’s opinionated, new and different. Ryan does a great job of describing a delivery system, that addresses some of the most common challenges in building and shipping software. Adopting the methodology lock-stock-and-barrel will be too much for most teams, but it has you wondering what could I borrow? Great read.

You Might Also Like:

image

Key Takeaways

The 20% that gave me 80% of the value.

  • Common pain points: Long projects, no time for strategic thinking, velocity falls over time
  • Shaping is up-front design work, that sets boundaries and reduces project risk before handing over to development teams

Part 1: Shaping

  • Shape at the right level of abstraction.
    • Too vague → Just right ← Too concrete
    • Wireframes are too concrete
    • Words are too abstract
  • Shaped work should be rough (room for the team), solved (thought through) and bounded (limited in scope).
  • Shaping defines what the feature does, how it works and where it fits into existing flows
    • Why does it matter? What would success look like? What customers are affected?
  • A two track process: shaping (done outside the team), building (done by the team)
  • Steps to shaping:
    1. Set boundaries
      • Start with the idea.
      • Set the appetite: How valuable is the idea?
        • How much time and attention does it deserve?
          • Small Batch (1-2 weeks)
          • Full Cycle (6 weeks)
      • Adopt Fixed time, variable scope
      • Watch out for grab-bags (refactors and redesigns are the worst offenders). Split these projects into smaller projects.
      • Your boundaries are in place when you have…
        • An Idea + an appetite + a narrow problem definition
    2. Find the elements
      • Move from words to elements of the software solution
        • What are the key components or interactions?
        • Where does it fit? How do you get to it?
        • Where goes it take you?
      • Try things at a high level (Breadboard)
        • Places: things you navigate to
        • Affordances: things a user can do
        • Connection lines: how affordances take the user from place to place
        • Elements are the output
      • Fat marker sketches make it impossible to add too much detail
      • Leaves room for designers
    3. Address risks and rabbit holes
      • Look for the pitfalls you can find up front and eliminate them before betting
      • Projects should have independent, well—understood parts that fit together in known ways
      • Walk through a use case in slow motion, every step. Look for holes in the concept, or edge cases that break the design or flow
      • Think about technical viability
      • Shapers prioritise quality and reduce risks. Keep elements that make the project worth doing? Can you cut off the big tail of risk?
      • Declare what you won’t do
      • Keep the clay wet → show them on a whiteboard
      • De-risked and ready to write up when…
        • Elements of the solution
        • Patches for rabbit holes
        • Declared areas that are out of bounds
    4. Write the pitch
      • Create a pitch, to present this as a potential bet.
      • Pitch Elements
        1. Problem: the raw idea, use case, or motivation
        2. Appetite: how much time we want to spend
        3. Solution: core elements, in an easy to understand form (sketches)
        4. Rabbit holes: things to call out to avoid problems
        5. No-gos: anything excluded from the concept
    5. Invite comments (to poke holes or contribute missing information)

Part 2: Betting

  • Make bets, not backlogs.
    • Before each 6 week cycle hold a betting table for stakeholders
    • Pitches are reviewed (all of which should be well-shaped, and had risks reduced)
    • Spread the responsibility for prioritising and tracking what to do across everyone
    • Important ideas come back
    • 6 week cycles everyone becomes available at the same time
      • Better than 2 week cycles, that are costly due to the planning overhead
    • 2 week cool downs between cycles: no scheduled work, everyone can meet and consider what to do next. Folks can work on what they want in the cool-down.
  • Small teams: 1 designer, 2 developers, 1 QA
  • The Betting table is a 2 hour meeting with the most senior doers (CTO, CEO)
    • Output of the call is a cycle plan.
    • It’s betting not planning. Bets have a payout, are a commitment, have capped downside
    • Uninterrupted time → when you make a bet you honour it
    • Bets or projects don’t get extended. If they don’t finish, it won’t happen. This stops runaway projects. Never carry scraps into next cycle
    • Bugs aren’t magically higher priority than everything else.
  • Three phases of work for building a new product:
    • R&D mode (led by senior members)
      • We don’t expect to ship anything at the end of the cycle
      • Learn what works, enough to define a structure, the form
      • We don’t commit to more than one cycle at a time
    • Production mode (formal cycles with shaping, betting and building phases)
      • It’s like working on an existing product
    • Cleanup mode:
      • All structure is thrown out the window.
      • Being near launch, everything gets real
      • There’s no shaping, but there is bug smashing
  • Questions to ask?
    • Does the problem matter?
    • Is the appetite right?
    • Are the right people available?
  • Post the kick-off message
    • A message goes out to the company at the end after the bets are made detailing what is being bet on for the next cycle, and who’s working on what

Part 3: Building

  • Handing over responsibility
    • Assign projects not tasks.
    • Done means deployed.
    • Get orientated. Spend the first few days as a team getting your head around problems.
    • Imagined vs discovered tasks. Teams discover tasks by doing real work. The way to figure out what needs to get done is by starting real work.
  • Get one piece done
    • Don’t create a master plan that’s got to come together at the last minute
    • Aim to make something tangible and demo-able early in the first week or so
    • Start in the middle (you don’t have to do sign up/login first
      • It should be core
      • It should be small
      • It should be novel
  • Map the scopes
    • Integrated project slices of value are called ‘scopes’.
    • Create a scope map (of all the different scopes/value slices) to divide the project into different territories
    • Scopes arise from interdependencies, which arise from doing real work. They can’t be defined upfront
    • The ‘scopes’ are right when…
      • you can see the whole project, and nothing important that worries you is hidden
      • conversations are now free flowing as you have a shared language for scopes
      • when new tasks come up, you know where to put them
    • Is your project a layer cake (balanced work Front-end/Back-end) or an Iceberg (more Back-end work)?
      • Question the icebergs, do you need the complexity?
    • Mark ‘nice to haves’ as such, so everyone is aware. Basecamp use ‘~’ to denote a nice to have task
  • Show progress
    • Shift the focus from what’s done or not done → to whats unknown and what’s solved
      • Once you’ve figured something out, you’re on the downhill when implementing
    • If something get’s stuck on the hill, what about the work is keeping it there? Help out.
    • It’s best to build your way up hill, not do it in your head
  • Sequence things right → choose the most important problems, with the most unknowns
    • Leave the least worrisome for last
  • Decide when to stop
    • Compare to the baseline, the current reality for customers.
    • Cycle limits motivate teams to limit scope
    • Scope grows like grass. Give teams the authority and responsibility to cut it down
    • Cutting scope isn’t lowering quality, it’s about asking what really matters
  • Move on
    • Let the storm pass. Everyone is focusing on the new thing and reacting to it. Avoid knee-jerk reactions. Remember why you made the change.
image

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Introduction

  • Growing pains of software teams:
    • Projects last long
    • PMs cant find time to think strategically
    • Founders ask, why can’t we release features as quickly as before?
  • Grew BaseCamp with just 10 hours a week of programming time. The tight constraint meant they learnt how to use it well.
  • Found it hard to articulate what they were doing to new hires.
    • Created cycles
    • Formalised pitching and betting process
    • Shaping = up-front design work we did to set boundaries and reduce risks on projects before handing over to development

Part 1: Shaping

  • Shape at the right level of abstraction
  • Too vague → Just right ← Too concrete
    • Wireframes are too concrete → don’t leave enough room for designers / creativity
      • Over-specifying the design leads to estimation errors → as some things are harder than they seem
    • Words are too abstract.
      • When a project is defined as a few words, nobody knows what it means
      • Not enough information for team members to make trade-offs
      • Often grow out of control because there’s no boundary to define what’s out of scope
‣
Level of fidelity they sketched their dot grid calendar to…
  • Properties of shaped work
    • It’s rough: everyone can tell it’s unfinished. Work that is too fine commits everyone to the wrong details. Leave room for judgement and trade-offs
    • It’s solved: it has been thought through. All the main elements of the solution are there, and they connect together. The overall solution is clear. Open questions have been removed to reduce risk.
    • It’s bounded: it indicates what not to do too. It tells the team where to stop.
  • Shaping is largely design work, it defines what the feature does, how it works and where it fits into existing flows
    • You need to be technically literate
    • It’s strategic → you have to be critical of the problem. Why does it matter? What would success look like? What customers are affected?
  • Two Tracks:
    • Shaping (kept private from building team, until confirmed)
    • Building
  • Steps to shaping:
    1. Set boundaries
    2. Rough out the elements
    3. Address risks and rabbit holes
    4. Write the pitch

1. Set Boundaries

  • Set boundaries on what you’re trying to do
  • Start with a raw idea ‘customers are asking for notifications’
  • Set the appetite: How valuable is the idea?
    • How much time and attention does it deserve?
      • Quick fix
      • Small batch (1-2 weeks)
      • Full Cycle (6 weeks)
  • Fixed time, variable scope is the key to shipping projects.
    • Apply this principle at each stage (shaping, building)
  • Good is relative. There’s no ‘best solution.’ Best is relative to constraints. Without a time limit, there’s always a better version. Good is judged relative to time and importance.
  • Don’t say yes or no on first contact with a new idea.
  • Narrow down the problem. Root cause problems, find the easier way. What could we build? → What’s really going wrong?
  • Watch out for grab-bags (refactors and redesigns are the worst offenders). Don’t do ‘2.0’ of anything. Split these projects into smaller projects.
  • Your boundaries are in place when you have…
    • Idea + appetite + narrow problem definition

2. Find the Elements

  • Getting from an idea in words to the elements of a software solution
  • Move at the right speed: have the right people in the room, don’t make wireframes too specific
  • Questions to answer:
    • Where in the system does the new thing fit?
    • How do you get to it?
    • What are the key components or interactions?
    • Where does it take you?
  • Breadboard (electrical engineering prototypes) →
    • Places: things you navigate to
    • Affordances: things a user can do
    • Connection lines: how affordances take the user from place to place
      • ‣
      Example:
  • Fat marker sketches make it impossible to add too much detail. Helps you avoid getting sucked into the weeds.
  • Elements are the output:
    • For Example the dot-calendar:
      • A 2-up monthly calendar grid
      • Dots for events, no spanned pills
      • Agenda-style list of events below that scrolls an event into view when you tap a dot
  • Leaves room for designers. It just sets the boundaries and rules of the game.
  • There are still significant unknowns to work through before this can be handed over to a team
  • You’ve added value to the raw idea, but haven’t spent so much time on it that you’re compelled to build it

3. Address risks and rabbit holes

  • We’re shaping work for a 6 week window
  • A single hole in the concept could blow out the piece of work
  • Look for the pitfalls you can find up front and eliminate them before betting on the project (then it becomes safe to bet on)
  • Rabbit holes, technical unknowns, unsolved design problems, or misunderstood dependencies.
  • Aim for a project with independent, well—understood parts that connect together in known ways
  • Did you miss anything? Did you make an technical assumptions that aren’t fair?
  • Walk through a use case in slow motion, every step.
  • Ask viability questions:
    • Does this require new technical work not done before?
    • Making assumptions about how parts fit together?
    • Assuming design solution exists we can’t come up with ourselves?
    • Is there a hard decision we should settle in advance so it doesn’t trip up the team?
  • Look for holes in the concept. Edge cases that break the design or flow.
  • Shapers prioritise quality and reduce risks. Can you keep all the elements that make the project worth doing? Can you cut off the big tail of risk?
  • Declare out of bounds: call out any cases you don’t want to support to keep the project within the appetite
  • Cut back → what can you remove whilst retaining the value of the feature
  • Present to technical experts → verify technical assumptions. Is this possible within the appetite? (E.g. 6 weeks)
    • Keep the clay wet → show them on a whiteboard
  • De-risked and ready to write up when…
    • Elements of the solution
    • Patches for rabbit holes
    • Declared areas that are out of bounds

4. Write the pitch

  • Until now the concept isn’t articulated well enough for somebody else to understand
  • Create a pitch, to present this as a potential bet.
  • Elements of a pitch:
    1. Problem: the raw idea, use case, or motivation
      • Present the problem and solution together
    2. Appetite: how much time we want to spend
    3. Solution: core elements, in an easy to understand form
      • Stay at high level, but add more concrete news
      • Help people set he dies whil not going too far into irrelevant details
        • ‣
        Embedded sketches
        ‣
        Annotated fat market sketches:
    4. Rabbit holes: things to call out to avoid problems
      • A few lines of text can address a rabbit hole
    5. No-gos: anything excluded from the concept
      • As above
  • Ready to present: post it to the betting table, or sell it live.
    • Invite comments (to poke holes or contribute missing information)

Part 2: Betting

  • Bets not backlogs
  • No backlogs → things just pile up there, we feel like we’re behind. You’ll waste time reviewing them.
  • BaseCamp instead before each 6 week cycle hold a betting table, where stakeholders decide what to do next
    • Pitches are looked at, and people can champion or revive previous pitches
    • Just well-shaped, reduced risk option
  • People can track pitches, bugs or requests independently without a central backlog
  • Spread the responsibility for prioritising and tracking what to do. Makes it a manageable task.
  • Important ideas have a way of coming back. Don’t overvalue ideas, ideas are cheap. The accumulate in huge piles.
  • Six week cycles make planning easier, as people all become available to work on something at the same time
  • 2 week cycles are costly due to the planning overhead.
  • 6 week cycles are long enough to finish something
  • After each 6 week cycle, there’s a 2 week cool-down. No scheduled work, everyone can meet and consider what to do next. Folks can work on what they want in the cool-down.
  • Small teams: 1 designer, 2 developers, 1 QA
  • Betting table
    • The Betting table is a 2 hour meeting: CEO, CTO, Senior Programmer, Product strategist
    • Knowledge of who’s available, what the priorities are, what kind of work we’ve done recently
    • Output of the call is a cycle plan.
    • It gives the C-suite hands on the steering wheel of the product
  • It’s betting not planning
    • Bet’s have a payout. The pitch defines a payout that makes the bet worth making
    • Bets are commitments. We commit to getting them done.
    • Bets are capped on the downside (max 6 weeks)
    • Uninterrupted time → when you make a bet you honour it
  • Bets or projects don’t get extended. If they don’t finish, it won’t happen
    • Stops runaway projects
    • Something went wrong in shaping, we need to re-shape and re-group
    • Provides motivation to the team and encourages ownership
  • Bugs aren’t magically higher priority than everything else. How severe are they? Many bugs can wait 6 weeks.
    • Use cool down or bring to the betting table or schedule a bug smash
  • Keep the slate clean, never carry scraps.
  • Place your bets
  • Three phases of work for building a new product:
    • R&D mode:
      • Be bet with time, not with a well-shaped pitch.
        • Time to refine the vision
      • Senior members (CEO, CTO) take it on
        • You can’t delegate what you don’t know yourself
        • Architectural decisions are really important
      • We don’t expect to ship anything at the end of the cycle
        • Spike don’t ship
        • Learn what works, enough to define a structure, the form
      • We don’t commit to more than one cycle at a time
    • Production mode:
      • After enough R&D cycles, the architectural decisions are settled.
      • The product has a structure that allows things to be added
      • Move to formal cycles with shaping, betting and building phases
      • It’s like working on an existing product
      • Only difference is that you’re pre-launch, can be more experimental
      • Reserve the right to cut features later on
    • Cleanup mode:
      • All structure is thrown out the window.
      • Being near launch, everything gets real
      • There’s no shaping, but there is bug smashing
      • There aren’t clear team boundaries, all hands to the pump
      • Keep discipline, and be clear what’s ‘must have’ and launch blocking
  • Questions to ask?
    • Does the problem matter?
      • Separate the problem and the solution. The solution doesn’t matter if the problem isn’t worth solving
      • We have to make choices, always more problems than time to solve
      • Have we understood the problem specifically enough? Can you narrow it to get 80% of the benefit with 20% of the change?
    • Is the appetite right?
      • Was the problem articulated well enough?
      • Understand the ‘no’s’ → sometimes the no to the time commitment is really a not to something else (solution, technology approach)
        • Does the no change if you reduce from 6 weeks to 2 weeks?
      • The shaper can choose to let it go
      • The shape can go back to the drawing board or do more research
    • Is the solution attractive?
      • Avoid doing design work or discussing the technical weeds. Do that when you’re building it
    • Sometimes its not the right time.
    • Are the right people available? It’s OK to wait for the right people, holidays can get in the way
    • Post the kick-off message
      • A message goes out to the company at the end after the bets are made detailing what is being bet on for the next cycle, and who’s working on what

Part 3: Building

  • Handing over responsibility
    • Assign projects not tasks. Trust the team to take on the entire project. Give as much freedom as you can (given the shape and cycle time limit)
    • Done means deployed. The proejct needs to be done within the time budgeted. That includes QA. Other teams handle help documentation, announcements etc.
    • Kick-off. Start with the pitch, give everyone the chance to ask questions.
    • Get orientated. Spend the first few days as a team getting your head around problems. Learn the codebase. The silence should break after a few days.
    • Imagined vs discovered tasks. Teams discover tasks by doing real work. The way to figure out what needs to get done is by starting real work.
  • Get one piece done
    • Don’t create a master plan that’s got to come together at the last minute
    • Aim to make something tangible and demo-able early in the first week or so
    • Connect the front-end to the back-end as soon as possible, find a value slice
    • Programmers don’t need to wait, the original shaping sketch gives them enough to go on
    • Simple designs with key components and affordances are passed as soon as possible
    • Code just enough to get to the next step
    • Start in the middle (you don’t have to do sign up/login first
      • It should be core
      • It should be small
      • It should be novel
  • Map the scopes
    • Organise by structure not person. Create lists based on the structure of the project, create lists of things that can be worked on and finished independently or each other
    • Integrated project slices of value are called ‘scopes’.
    • Create a scope map (of all the different scopes/value slices) to divide the project into different territories
    • Scopes arise from interdependencies, which arise from doing real work. They can’t be defined upfront
    • The ‘scopes’ are right when…
      • you can see the whole project, and nothing important that worries you is hidden
      • conversations are now free flowing as you have a shared language for scopes
      • when new tasks come up, you know where to put them
    • Scopes might need to be redrawn if…
      • It’s hard to say how done scope is
      • The name isn’t unique to the project (e.g. front-end)
      • It’s too big to finish soon
    • Is your project a layer cake (balanced work Front-end/Back-end) or an Iceberg (more Back-end work)
      • question the icebergs, do you need the complexity?
    • Mark ‘nice to haves’ as such, so everyone is aware. Basecamp use ‘~’ to denote a nice to have task
  • Show progress
    • Remember there’s a difference between imagined tasks and discovered tasks. To-do lists actually grow as work progresses
    • Estimates don’t show uncertainty.
    • Shift the focus from what’s done or not done → to whats unknown and what’s solved
        • ‣
        Diagram
      1. Once you’ve figured something out, you’re on the downhill when implementing
      2. BaseCamp developed a tool to visualise this
    • If something get’s stuck on the hill, what about the work is keeping it there? Help out.
    • It’s best to build your way up hill, not do it in your head
  • Sequence things right → choose the most important problems, with the most unknowns
    • Leave the least worrisome for last
  • Decide when to stop
    • Compare to the baseline, the current reality for customers.
    • Cycle limits motivate trade-offs. Teams will actively limit scopes, because they have to ship
    • Scope grows like grass. Give teams the authority and responsibility to cut it down
    • Cutting scope isn’t lowering quality, it’s about asking what really matters
      • is this a must-have?
      • could we ship without it?
      • 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? what’s the impact if it does?
    • Only extend a project if…
      • outstanding tasks are must-haves
      • outstanding work must all be downhill
      • you can continue within the appetite for the project
  • Move on
    • Let the storm pass. Shipping can create more work. Everyone is focusing on the new thing and reacting to it. Avoid knee-jerk reactions. Remember why you made the change.
    • Remember the bet is over.
    • Feedback needs to be shaped

Recap

  • Shape work, don’t take on un-shaped work
  • Set appetites, not estimates
  • Design at the right level of abstraction
  • Concept with breadboards and fat marker sketches
  • Making bets with a capped downside
  • Honour bets with uninterrupted time
  • Choose longer cycles (6 weeks)
  • Have a cool-down period between cycles
  • Breaking projects apart into scopes
  • Downhill versus uphill work and communicating about unknowns
  • Scope hammering to separate must-haves from nice-to-haves