Topics include:

• Why "fixed time, variable scope" is so important for actually getting things done
• Integrating development and design into a single process instead of design first, develop later
• What it means to "shape" work before deciding to work on it
• What it means to "bet" on a project, and why Basecamp would rather trash a project than extend the deadline by an extra week
• Taking deadlines seriously, and how it empowers teams to make their own decisions about scope to avoid having to trash the project
• An example of a project at Basecamp that failed to ship, and working through what they did wrong that led to that outcome
• De-risking projects by getting input from technical experts on the team before committing to actually doing the work
• 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?
• The difference between macro planning and micro planning on a project
• How Basecamp avoids iterating on solutions within a cycle without turning projects into fixed time, fixed scope
• 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
• Applying "Shape Up" on client projects

Sponsors:

• Tuple, try the best pair programming app out there for free for two weeks

Links:

• Shape Up: Stop Running in Circles and Ship Work that Matters, Ryan's recent book about how they work at Basecamp