Restructuring Our Internal Technical Development Process

We have decided to restructure of technical development process by planning our development projects into 6-week sprint periods followed by a 1-week cooldown.

6-week sprint cycles are used by some of the most productive and reputable tech companies such as Intercom, Buffer, Basecamp as well as hundreds of others.

A 6-week sprint can be made up of Large Batch Work and Small Batch Work. Large batch work refers to a short task list made up of bigger projects (Eg: one big new feature or redesign). Small batch work refers to a sprint with many smaller objectives. 

Why are we doing this now?

We are now at a place where we have the infrastructure (ie: enough developers) setup solely to work on rebuilding pages and adding new features. At the moment, we want to tear down the current application as efficiently as possible so that we can start building new functionality on our new platform. This new system will also present a clear picture of what customers can expect to see in the next 6 weeks. Lastly, this will optimize the support to development handoff.

Key Components

• One Cycle At a Time - We do not plan anything past the 6 week cycle. If something isn’t scheduled in a cycle it doesn’t have an ETA.
• Uninterrupted Time - We are focusing only on what is scheduled for the cycle. If a feature or minor bug comes up, it waits until the end of the cycle.

Cooldown - After the cycle is complete, developers will work on any minor bugs/improvements they want to make (typically for 1-2 weeks). The new cycle will start being planned during this time.

What will be different?

With a small team, it will be very difficult to not address any major issues and will need to break up 6-week cycle work to do it. When a big issues comes in the door, a developer will need to stop what they're doing to solve it immediately. However, some issues will need to wait. We’ll take it on a case by case basis.

Cooldowns may be shorter than the typical 2 weeks. Since we are still rebuilding a lot of the back-end we probably will shorten this for now in order to move onto the next 6-week sprint more quickly.

What about feature requests?

Companies that use 6 week cycles typically follow the “No Backlogs” rule which means the new feature requests will not be tracked or logged. The new 6-week sprint will be decided using input from sales and customer support teams (in TeamBuildr's case: Ali, Luke, Ryan, Hewitt).

For us, we are going to add them to a Feature Request board and try to work through them during pre-cycle planning by prioritizing features that currently benefit existing customers while balancing new features that will expand our platform's capabilities.