Like many working in product, I’ve been a follower-slash-admirer of how Basecamp works for years.

This model of working in 6-week “cycles” sounds like an attractive option for organizing a team, without falling into the onion-slicing trap of what agile can become — where more time is spent microscoring, tracking, and measuring velocities than on defining what needs to get done and why.

Once a six week cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six week cycle. Ample time for context switching. We also use this time to firm up ideas that we’ll be tackling next cycle.

I like the idea of spacing the cycles for the inevitable bugfixes, polishes, and the randomness that crosses the transom unexpectedly. And, importantly, it leaves time for the product team to think through planning out what to slot for the next cycle, and exactly how things should be build (see more about Ryan Singer’s hill charts). Another topic is on how to tackle The Big Stuff. Fried’s point on how they do that is to do some “scope hammering” — chop it down to whatever the 6-week version looks like:

The secret to making this possible is something we call scope hammering. We take the chisel to the big block of marble and figuring out how to sculpt, nip, and tuck a feature into the best six-week version possible. It’s all about looking carefully at a feature and figuring out the true essence. Not what can it be, but what does it need to be?

Before any project is included in a cycle, we’ve already figured out what we think the six week version is. We don’t include planning in the cycle time — all the planning and consideration happens in the pitch. It has to happen before the work is slated to be done by a team. That way the six weeks is all implementation and execution. No time is spent on big unknowns — we try to make sure all the big stuff is known enough before we get started.

This process would improve things for many folks, but could very well be unworkable for others. The article links to an example kickoff note that shows what one of the Basecamp work cycles looks like. I’m always fascinated to see new ideas on how teams work together.

I’ve always been largely agnostic to systems in terms of which is better than another writ large. If a system increases your team’s output from 3 to 5, or from 4 to 7 on the whole, it’s a good system. That doesn’t mean there aren’t better ways to tweak or optimize, but there’s too much “that sucks, this is better” literature out there that confuses folks.

Use what works, and continue experimenting cautiously but confidently.