Our Engineering Process
This document outlines how we work as an engineering team. Inspired by many, but more recently by Basecamp’s 6 week cycles as described by their CEO, Jason Fried.
We work in four week cycles
Every four weeks we start a new cycle of work. Each cycle contains two types of projects:
Big Feature: These are big features or projects that will take up to four weeks to get done. We’ll typically take on one or two Big Features in a cycle.
Small Feature: These are small features, bugs, tweaks and requests that we want to roll out in a given cycle. They typically will take anywhere from a couple of days through to a couple of weeks. We’ll typically take on seven to ten Small Tasks in a cycle.
At the end of a four week cycle, we kick off a one week planning period which we use to plan the next cycle, work on side projects, clean up small bits and pieces and take a bit of a breather to switch context before we gear up for the next cycle.
Building the four week version
If a given Big Feature is expected to take longer than one cycle to be feature complete, we expect to ship the “four week version” of that feature in a given cycle, followed by the “eight week version”, the “twelve week version” and so on. This will push us to hammer down the scope of a given feature to its “four week version”, and will push us to keep shipping Big Features every cycle.
We expect Small Features to ship as soon as they’re ready, regardless of how far along the cycle we may be.
Ad-hoc Assembled Teams
Each Big Feature is assigned to a team assembled to build that feature or project. If we take on two Big Features during a cycle, we’ll have one team working on one project and another team working on the other.
Small Features will all be done by one team, again assembled for that cycle.
A team should ideally be two or three people, depending on the type of work. Either one engineer and one designer, or two engineers and one designer. Teams should not exceed this number as communication and productivity starts to break down, and complexity increases dramatically.
During the planning week each individual should be asked what they’d ideally like to be working on in the next cycle and this should be used as a guide whilst assembling a team. The VP of Engineering, Engineering Leads and the SVP of Product will work together to pick what will go into the next cycle and to allow a team to coalesce around a feature or assign individuals to a given team based on their preferences. Final responsibility for team assembly will fall on the VP of Engineering.
Teams will stay together for the full cycle and will re-assemble in a new configuration for the next cycle, but may choose to stick together for a few cycles. There isn’t a hard rule about this!
Do we have dedicated project managers?
No, because it isn’t efficient.
The designer on the team leads the project, but has a very close working relationship with the engineer(s) on the team. They work together on everything.
No matter the role, we all track our work on Asana and communicate on Slack. No major decision should be made on Slack without it reflecting back on the relevant feature task or card on Asana.
While it would be ideal to have everything in one place, Slack is great at allowing us to communicate fluidly, whilst Asana is the right fit for us from a full team project management perspective. We’ve tried many many tools, and this is the right combination at this time. It is however likely that it’ll change at some point, as the only consistency is change.
We continue to use GitHub to manage our code as well as to manage issues that relate back to feature cards in Asana, but this is something that we need to re-look at from an efficiency perspective in the near future.
Do we track time or carry out task estimations?
No. We don’t measure efficiency or compare actuals vs. estimates. We have four weeks to get something done. How a team decides to get it done during that time is up to them.
It is important that we don’t allow ourselves to run to the end of a cycle before realising that we’re out of time. We should always be looking at what’s done, what’s left and how much time is left. Our scope should always be changing, adjusting down if we’re running low on time, or ramping up if we have more time. It’s a fluid process that we’re always negotiating with each other on. What isn’t fluid is our deadline — four weeks from when we started.
[This topic remains under development]