131: Ryan Singer - How Basecamp Builds Software
O epizodě podcastu
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
- Tuple , try the best pair programming app out there for free for two weeks
- Shape Up: Stop Running in Circles and Ship Work that Matters , Ryan's recent book about how they work at Basecamp
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
Popis podcastu
A podcast for developers interested in building great software products. Every episode, Adam Wathan is joined by a guest to talk about everything from product design and user experience to unit testing and system administration.