fuchsbau

Shape Up, Ryan Singer

(back to books)

---

• Substrat: main risk to be mitigated is not shipping on time
  • underspecified projects grow out of control (OOC) because nothing is out of scope
• main ideas
  • six-week cycles: see end from beginning, long enough to build sth
  • shape the work: narrow down problem, design solution for appetite
    • small senior group shapes next cycle in parallel to current cycle
  • responsible teams: integrated team (1 designer + 1-2 programmers)
• process
  • shaping: set appetite (1-2 weeks or 6 weeks) on raw idea, sketch solution, write pitch
    • properties: rough, solved, bounded (incl. likely pitfalls)
    • 5 pitch elements: problem, appetite, solution, rabbit holes, no-gos
    • well-shaped work = thin-tailed probability distribution of risk
  • betting: choose among pitched projects (only those brought forward)
    • good questions to ask: "Does the problem matter?", "Is the appetite right?", "Is the solution attractive?", "Is this the right time?", "Are the right people available?"
  • building
    • important: sth demoable in ~1 week (core, small, novel)
    • mark nice-to-have tasks with ~
    • uphill (figuring out what to do) and downhill phase (executing)
    • circuit breaker: by default no extension for unfinished projects
  • 2 week cool down after cycle (don't mix deadline & planning pressure)
• ideal reply to ideas: "maybe some day" --> soft no with optionality
• fat marker sketch: rough early stage of project
  • avoid: "I know I drew it like this but ignore that ..."
• breadboarding: electrical eng prototype with full components but no design
  • places (what you navigate to), affordances (buttons/fields), connections
  • a) start with place and underline it, b) add affordances underneath place, c) connect affordance with new place
• Basecamp's structure at time of book: Core (shaper & cycle teams), SIP (Security, Infrastructure, Performance), Ops, Support
• recommendations:
  • don't keep backlogs (let people instead raise topics again)
  • fix shipping before you fix research & discovery
  • once per year one cycle (before holiday season) for bugs ("bug smash")
  • don't do "redesigns" or "refactorings" without clear problem
  • create to do lists by structure (what can be worked on independently), not by persons
  • chowder list: loose tasks that don't fit anywhere
  • quicker decisions: don't compare up to ideal, compare down to baseline
  • teams can ship without code review if they want