131: Ryan Singer - How Basecamp Builds Software

What It Covers

Ryan Singer explains Basecamp's Shape Up methodology for delivering software reliably through fixed six-week cycles with variable scope, integrated design-development collaboration, and upfront shaping work that eliminates project risks before teams start building.

Key Questions Answered

• •Shaping before betting: Teams receive shaped work with clear boundaries and solved technical risks, not open-ended problems like "build a calendar." Shaping defines what's in scope, what's out, and eliminates rabbit holes through fat marker sketches and breadboards before any six-week commitment begins.
• •Fixed time, variable scope enforcement: Six-week cycles end with a circuit breaker that kills projects by default if incomplete. No extensions without re-competing at the betting table against new work. This forces real trade-offs and prevents projects from dragging eighteen weeks when scoped for six.
• •Integration over handoffs: Designers write HTML, CSS, and templates while programmers handle models and controllers. Designers stub affordances first with placeholder styling, programmers wire functionality, then designers iterate on polish in parallel. This eliminates waiting on pixel-perfect mockups before coding starts.
• •Scope management through orthogonalization: Teams identify independent vertical slices they can complete and never revisit, like solving one form's UI completely before touching the listing view. This factoring approach prevents scope creep better than iteration, since you can't iterate forever when the circuit breaker looms.
• •Two-week cooldown periods: Between six-week cycles, teams have unstructured time for bug fixes, learning, and technical consultation on upcoming shaped work. This creates space for shaping feedback without interrupting cycle work, and prevents the Jira paper shredder effect of constant context switching.