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.

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
     • 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-Go: 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 prioritizing 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 honor 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 uses ‘~’ 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 gets 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.