The Six Week Cycle

Roughly every six weeks we start a new cycle of product work. Each six week work cycle contains two types of projects:

• Big Batch: Big Batch projects are big features or stuff that’s going to take six weeks to complete. We typically take on one or two Big Batch projects in a six week cycle.
• Small Batch: Small Batch projects are smaller things: tweaks, minor adjustments, and easy adds that should take anywhere from a day to two weeks to complete. We typically take on between four and eight Small Batch projects in a six week cycle.

To give you a sense of what kind of projects might fit into Big and Small, here’s an internal post announcing a cycle’s worth of work.

Once a six week cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix up something, pick up a pet project, reflect, 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.

Note: These are not sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can. It’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

Six weeks… What if something’s so huge it’s going to take longer?

We believe there’s a great six week version of nearly everything. Occasionally something falls outside of this limit — deep Research & Development projects, brand new tech we’ve never used before, etc. But we’ve come to discover that nearly everything important can be done in six weeks or less. And done well.

The secret to making this possible is something we call scope hammering. We take the chisel to the big block of marble and figure out how to sculpt 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 and understood before we get started.

Who does the work?

Each Big Batch project is assigned a team. So if we take on two Big Batch projects during a cycle, we’d have one team working on one project and another team working on the other. Small Batch projects are all done by one team. Teams stay together for the full cycle.

A team is two or three people, depending on the type of work. Either one programmer and one designer, or two programmers and one designer. That’s it. No teams of four, five, or six. Everything we take on has to be done by a team of three, max.

We think three is the ideal size for most things — complexity increases exponentially beyond that.

Teams are assembled ad hoc. Before a cycle begins, we ask each person what kind of work they’d like to do over the next six weeks. Teams either coalesce around areas of interest, or we assign people to a team based on their preferences. Teams often change up after the cycle so everyone gets a chance to work with different people, but sometimes they stick together for a few cycles. There are no hard and fast rules about this.

Do we have dedicated project managers?

No. The designer on the team leads the project, but there’s a very close working relationship between designer and programmer(s). They work together on everything.

No matter the role, everyone tracks work in the same place, communicates in the same place, etc. For us that place is Basecamp 4. When everything’s in one place, everyone knows where things are, where things stand, and everyone can be self-sufficient. Splitting work and communication and management across separate tools/products is 1. a highly inefficient, and 2. makes it very difficult for the whole team to see the whole picture.

Do we track time?

No. We don’t measure efficiency, compare actuals vs. estimates. We have six weeks to get something done. However a team decides to get it done during that time is up to them.

What is important is that we don’t run up to the end and figure out we’re out of time. We’re always looking at what’s done, what’s left, and how much time remains. Scope is ever changing — adjusting down if we’re running low on time, or ramping up if we find we have more time than we thought. It’s a negotiation. It’s a very fluid process. What isn’t fluid is the deadline — six weeks from when we started.

Where do ideas come from?

We don’t have distinct time set aside to come up with ideas. There’s not a distinct set of people who come up with all the ideas. Ideas come from all over, and are offered up any time. They come from us, they come from customers. There’s always an ocean of ideas. Every once in a while a bubble floats out of the ocean and lands on the shore. That’s when we begin to take a closer look.

Pitching an idea

When an idea feels formed enough, it’s turned into a pitch. A pitch is a fully-formed definition of the problem as well as a proposed solution.

Here’s an example of a pitch so you can see the general form they take. We don’t pitch in person — we always write up pitches and post them to Basecamp for review.

Why don’t we pitch in person? For a few reasons:

1. We feel it’s better to write something up completely. This forces the floor — the person who’s making the pitch can’t be interrupted. They are guaranteed to be able to present their story completely, exactly as they want.
2. Further, we believe writing things out makes you consider them at a deeper level.
3. We’re big believers in asynchronous communication — write it down now and other people can absorb it later when they’re ready. Real-time communication in person or virtually forces synchronization of schedules which is highly inefficient.
4. And last, when it’s posted to Basecamp as a message, all feedback and follow up questions are automatically attached to the original post. This keeps all communication about the pitch centralized in one place on one page so everyone has access to the same story. One version of the truth.

How do you decide which projects to take on?

It's more art than science. Ideas come from everywhere, but ultimately the decision about what makes it into a cycle comes down to Jason (CEO) and David (CTO). A week or so prior to the cycle start, they review all the pitches posted to Basecamp, share some of their own ideas as well, and often vigorously debate the options. And then they'll often have a call (Skype or Hangout) for 30 minutes, debate some more, and make the final decisions.

What makes the cut depends on many variables — how complete the pitches were, where customers are feeling pain, where we have new ideas we want to try, where stuff feels janky and needs revisiting, business cases we’re trying to make, etc. But whatever the decisions, the good news is that in six weeks we can start all over again with another batch of work. So if something doesn’t make it in, we can consider it again in just a month and a half.

How does the cycle get announced?

Once the cycle has been defined, and work grouped into Big and Small Batch projects, Jason writes up an announcement and posts it to the “Building BC4” project inside Basecamp. The Building BC4 project is the master project for high level Basecamp-related product work. It’s where we talk big picture items, share pitches, discuss ideas, schedule the cycles, etc.  Here’s that sample cycle announcement again.

How is the actual work organized?

Each Big Batch project gets its own Basecamp project. Here’s an example of one from a recent cycle:

How does Quality Assurance work?

Members of the QA team roam between ongoing projects, invited in by the teams when they want something checked and double checked. We’ve found that the earlier they’re involved the better. QA fits into the six week time frame too, so nothing busts a deadline like a pile of last minute QA findings. (That’s why we don’t wait until the end to start QA.)

How are Jason and David involved?

David and Jason are involved at some level in nearly every customer-facing project and product update.

Jason works with the designers to explore ideas early and help refine and simplify things as we go. He also works with the designers on copywriting — making sure the words we’re using make sense. Design reviews aren’t critiques, they are problem solving sessions.

David helps the programmers figure out the plan of attack — thinking through the models, maintaining our focus on performance and speed, and negotiating technical compromises that make six week time frames possible.

As mentioned, Jason and David are also both involved in the product planning stage — pitching ideas and figuring out what work makes a given cycle. They work closely with our team leads to think through each feature and look at the product holistically to figure out what makes sense where and when.

Next up: Tracking the work on Hill Charts →