Date: Wed, 01 Jan 2020 21:15:00 +0000
<p>Topics include:</p><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><p>Sponsors:</p><ul><li> <a href="https://tuple.app">Tuple</a>, try the best pair programming app out there for free for two weeks</li></ul><p>Links:</p><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>
