Topics include:<ul><li>Why "fixed time, variable scope" is so important for actually getting things done</li><li>Integrating development and design into a single process instead of design first, develop later</li><li>What it means to "shape" work before deciding to work on it</li><li>What it means to "bet" on a project, and why Basecamp would rather trash a project than extend the deadline by an extra week</li><li>Taking deadlines seriously, and how it empowers teams to make their own decisions about scope to avoid having to trash the project</li><li>An example of a project at Basecamp that failed to ship, and working through what they did wrong that led to that outcome</li><li>De-risking projects by getting input from technical experts on the team before committing to actually doing the work</li><li>What exactly is the deliverable a design/development team receives from leadership at the start of a project that they are expected to be able to succeed with?</li><li>The difference between macro planning and micro planning on a project</li><li>How Basecamp avoids iterating on solutions within a cycle without turning projects into fixed time, fixed scope</li><li>Why designers at Basecamp start by actually building the very rough "Times New Roman" version of a UI with HTML and CSS before spending time on high fidelity visual design decisions</li><li>Applying "Shape Up" on client projects</li></ul>Sponsors:<ul><li><a href="https://tuple.app">Tuple</a>, try the best pair programming app out there for free for two weeks</li></ul>Links:<ul><li><a href="https://basecamp.com/shapeup">Shape Up: Stop Running in Circles and Ship Work that Matters</a>, Ryan's recent book about how they work at Basecamp</li></ul>

131: Ryan Singer - How Basecamp Builds Software