Heads up! This page uses features your browser doesnât support. Try a modern browser like Firefox or Chrome for the best experience.
The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The wayâthe howâis foundational and fundamental.
Youâll often hear people say âexecution is everything,â but thatâs not quite right. In fact, itâs often quite wrong.
When it comes to project work, and specifically software development, executing something the wrong way can destroy morale, grind teams down, erode trust, crunch gears, and wreck the machinery of long-term progress. So yeah, itâs âdone,â but at what cost? By doing, what have we done to ourselves? Do we really have to do that again, over and over month after month, year after year?
How many projects have you been a part of that youâd want to do over? How many projects have gone long, piled up at the end, and burned people out? How many projects were essentially collections of unreasonable expectations? How many projects turned teams against each other, frustrated everyone from builder to stakeholder, and ultimately would have been better off dying than delivering?
Sometimes execution is everythingâeverything thatâs wrong. So what does executing right look like?
Over the last few years, thereâs been a heightened curiosity about how we work at Basecamp. People often ask us how we get so much done so quickly at such a high level of quality with such a small team. And how we keep our teams together for years and years.
For one, weâre not into waterfall or agile or scrum. For two, we donât line walls with Post-it notes. For three, we donât do daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking, none of that.
We have an entirely different approach. One developed in isolation over nearly 15 years of constant trial and error, taking note, iterating, honing in, and polishing up. Weâve shaped our own way.
Blog posts, workshops, and occasional conference talks have provided glimpses of our own unique process, but weâve never laid it bare for all to see. This book does just that.
Now that our process is fully formed, documented, and ready to go, weâre here to share it with all those curious enough to listen to a new way of doing things. Explorers, pioneers, those who donât care what everyone else is doing. Those who want to work better than the rest.
Donât think of this as a book. Think of it as a flashlight. You and your team have fumbled around in the dark long enough. Now youâve got something bright and powerful to help you find a new way.
We hope you find it interesting, enlightening, and, most of all, helpful.
Thanks for reading.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4