Jaksokuvaus
Topics include:Why "fixed time, variable scope" is so important for actually getting things doneIntegrating development and design into a single process instead of design first, develop laterWhat it means to "shape" work before deciding to work on itWhat it means to "bet" on a project, and why Basecamp would rather trash a project than extend the deadline by an extra weekTaking deadlines seriously, and how it empowers teams to make their own decisions about scope to avoid having to trash the projectAn example of a project at Basecamp that failed to ship, and working through what they did wrong that led to that outcomeDe-risking projects by getting input from technical experts on the team before committing to actually doing the workWhat 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 projectHow Basecamp avoids iterating on solutions within a cycle without turning projects into fixed time, fixed scopeWhy 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 decisionsApplying "Shape Up" on client projectsSponsors:Tuple, try the best pair programming app out there for free for two weeksLinks:Shape Up: Stop Running in Circles and Ship Work that Matters, Ryan's recent book about how they work at Basecamp