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:

Book Summary: Build by Tony Fadell

Get a comprehensive summary of the best-selling book "Build" by Tony Fadell, the father of the iPod. Learn about Tony's journey as an entrepreneur and innovator, and gain valuable insights on how to create and scale successful products.

andrewclark.co.uk

How to Lead in Product Management

Roman is one of my favourite product management authors. His concise, to-the-point writing style is incredibly respectful of your time. He delivers wall-to-wall concepts without any storytelling fluff, providing just enough prose to get the point across.

andrewclark.co.uk

Book Review and Summary: The Mythical Man Month by Fred Brooks

Get a comprehensive review and summary of the classic book "The Mythical Man Month" by Fred Brooks, the software engineering and management expert. Learn about the key principles and practices for managing software development projects and teams effectively.

andrewclark.co.uk

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.

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