Six-week cycles
Basecamp works in six-week cycle sprints. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.
The majority of their features are built and released in one six-week cycle.
The decisions are based on moving the product forward in the next six weeks, not micromanaging time. They don’t count hours or question how individual days are spent. They don’t have daily meetings. Focus is at a higher level.
The cycle
Calendars Dilemma
Committing time and people is difficult if we can’t easily determine who’s available and for how long.
When people are available at different times due to overlapping activities, planning turns into a frustrating game of Calendar Tetris. Working in cycles drastically simplifies this problem. A cycle gives us a standard planning size both for shaping and scheduling.
Basecamp learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead. The amount of work you get out of two weeks isn’t worth the collective hours around the table to “sprint plan” or the opportunity cost of breaking everyone’s momentum to re-group.
Longer cycles
This led them to try longer cycles. We wanted a cycle that would be long enough to finish a whole epic, start to end. At the same time, cycles need to be short enough to see the end from the beginning. People need to feel the deadline looming in order to make trade-offs. If the deadline is too distant and abstract at the start, teams will naturally wander and use time inefficiently until the deadline starts to get closer and feel real.
After years of experimentation, they arrived at six weeks. Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning.
Breathing
If they were to run six-week cycles back to back, there wouldn’t be any time to breathe and think about what’s next. The end of a cycle is the worst time to meet and plan because everybody is too busy finishing activities and making last-minute decisions in order to ship on time.
Therefore, after each six-week cycle, they schedule two weeks for cool down This is a period with no scheduled work where they can breathe, meet as needed, and consider what to do next.
During cool-down, programmers and designers on teams are free to work on whatever they want. After working hard to ship their six-week stories, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities.
During the cool-down, there is also the strategic planning activity for the upcoming six-weeks cycle.
Bugs
They fix them, if they are not critical:
during cool-downs
in a bug smash, which they do once a year and they clear the backlog of bugs
Team
Their teams consist of either one designer and two programmers or one designer and one programmer. They’re joined by a QA person who does integration testing later in the cycle.
These teams will either spend the entire cycle working on one story, or they’ll work on multiple smaller stories during the cycle.
Sources: