We run on 6-week budgets for most major product work at Basecamp. It’s not that everything has to done in that time, but the self-imposed constraint makes us try. It’s not a deadline, mind you, but a budget. Deadlines are just excuses for death marches (fixed scope, fixed time). Screw deadlines.
Budgets, on the other hand, instruct us to keep quality high but scope variable. When making decisions on how to fit within budget, we decide to write less software. Fewer features, fewer settings, fewer wouldn’t-it-be-cool-if’s.
Nothing brings clarity to the discussion like “well, there’s only 3 weeks left: We can either do A and B, but not C. Or just C. Which would you rather?”. It moves the debates out of the we-really-ought-to realm. That’s the realm free of compromise and trade-offs. That’s the realm of bloated, late software.
This might make it sound easy to ship great software on time, but of course it’s not. Because like any good constraint, it hurts when its working. We have to kill our darlings all the time. Features, settings, considerations that we really think are important have to be cut constantly. When something you believe to be important doesn’t make it, it hurts.
But it’s also the right thing to do. We’ve proven that time and time again. Things we thought were terribly important in the heat of the argument frequently turns out not to matter at all. And above all, the discipline and the habit of shipping software every six weeks (or thereabouts) is worth some real sacrifice.
We’ve run other intervals in the past, and we sometimes do when circumstances warrant. Our standard used to be two months, but we’d still go a week or two over budget with that schedule. And it’s not clear that the software we shipped was appreciably better. Now we only run on 8-week cycles over the Summer when we work four days a week instead of five.
Shipping software on a budget rather than on a deadline or When It’s Done is a key component to how we’ve written and released so much with such a small team for so long. It’s probably been the most helpful general concept we’ve adopted from agile development. It doesn’t even require a big process, a backlog, or a stand-up meeting. But it will occasionally hurt. That’s when you know it’s working.
