Up until pretty recently my company’s tech team managed its projects through a Kanban-board. In practice this entailed that we’d come up with a product roadmap for the 12 months ahead and would start working on this from top to bottom, moving tickets through the usual swimming lanes as we went.
Enter: Development hell
Whenever a product request would arise that appeared urgent – whether this would be a feature request from a customer, an idea from the CEO or a bug – we’d just add this to our to-do list, allowing it to get tackled by the first available developer.
After, all this is one of the central underpinnings of agile development, correct? You’re keeping yourself lean, flexible and swift at nearly any costs. The world is changing at an ever-accelerating pace, and as a team you’d want to adhere to this fact by shifting your focus to whatever appears most worthwhile to work on at that particular moment.
And initially, this philosophy served us well. We were deploying project after project and our product improved on pretty much a weekly basis. Spontaneous ideas could just be chucked on top the to-list of our Kanban board and ended up getting developed in no-time.
But at a certain point something odd happened. Projects seem to be dragging out forever. Nothing ended up getting properly finished. Developers started to get burned out. And the product was stagnant, month after month.
What was happening?
In order to find out, I commenced a search for a new product development framework. We needed some kind of structure, containing certain restrictions which would force creativity, allowing us to rapidly develop polished, high-quality projects. At the same time, we needed something that was sufficiently agile to allow us to keep moving fast and work on things of relevance. The process needed to be repeatable throughout the year. We needed something with more substance but less intensity than scrum-sprints.
All of scrum’s detailed estimations of stories and tight sprint time frames of 2 weeks aren’t practical given the immense overhead the necessary planning brings. And as 2 weeks often end up being too short to ship something meaningful, you’re still dealing with projects which are dragging on forever, albeit in 2-week chucks.
The solution: The 6-week cycle
What ended up being a perfect solution for us was splitting our development work in 6-week cycles. Every 6 weeks we kick off a new product cycle. Every cycle consists of the following type of project:
- Big Batch: Big Batch projects are comprehensive features or projects which will require the full 6 weeks of the cycle. A cycle usually contains 2-3 of such projects.
- Small Batch: Small Batch projects are little improvements, adjustments or bugs which can be developed in anywhere between a day and 2 weeks. Our cycles usually contain between 6-8 small batch projects.
To illustrate what this looks like in practice, have a look at one of our memos announcing a cycle.
After we’ve wrapped up a 6-week cycle, we enter a 2-week cool-down. Throughout this, our developers are free to pick up company-related pet projects, implement improvements or explore new technologies, without being tied up to a schedule. This fosters creativity and stimulates energy levels.
Furthermore, we use this time to determine which projects we’ll pick up for the next cycle.
How do we plan for the upcoming cycle?
Whenever we kick off a new cycle, we work in parallel on new product ideas for the next cycle. Right after we wrap up a cycle, during the cool-down, we’ll plan a meeting during which we’ll discuss our pitches for the next cycle. Pitches are projects which have been developed during the previous cycle by our product team.
A meeting like this can work up to 2 hours. The team members participating are a few senior members of the dev team, the CEO and myself. Ahead of the meeting, everyone should have studies the pitches carefully. The goal of the meeting is to determine which pitches will make the final cut for the upcoming cycle.
How do you ensure that big batch projects won’t exceed the 6-week limit?
We firmly believe that nearly any project as a great “6-week version.” There are of course always exceptions. For instance, when you’re developing a new product from scratch, or developing something with a whole new technology. But you’ll find out that nearly anything of substance can be developed in 6 weeks (or less).
Key is to look at a project of what it should be instead of what it could be. This will lead to hammering down the scope of your project even before you commence developing. You’ll apply laser focus on a feature’s essence and ignore all else.
When you then start developing the project, you will be faced with little to no major surprises. That way, the 6-week cycle is all about implementation and execution - not planning.
To ensure you won’t exceed the 6 weeks of the cycle you’ll also have to safeguard your tech team. This means denying “quick” product requests originating from, say, your sales team. Things go awry quickly once a non-engineer starts to think “shouldn’t this be a 5-minute job?” What might appear from the outside as something that can be solved in 5-minutes can end up taking 3 hours.
On top of that you’ll end up dealing with the costs of task switching. If an engineer is suddenly required to abruptly work on a new task, you’ll kill his flow. Engineers don’t chop up their days in many little pieces as a marketeer or salesperson might: they require long uninterrupted hours of deep work.
And so these “5 minute” requests can end up killing your engineer’s morning. Killing his morning, might subsequently disintegrate his day.
And there you have it: you’ll exceed the 6 weeks of your cycle.
But what if someone discovers a bug during a cycle? Surely you’d want to tackle this straight away?
All software has bugs. There is nothing special about them. It sometimes occurred that we discovered a bug that had been there for months. Sometimes a user made us aware about a bug. The tendency was often to throw that bug at the top of our to-do list and fix it as quickly as possible.
We don't do this anymore. If a bug is reported, we'll take note of it, and a developer may pick it up during the cool-down at the end of the cycle. Is this bug not spontaneously picked up by a developer, but do we consider solving the bug as crucial? Then it can be pitched for the upcoming cycle. But the bug will not be added to the current cycle.
The exception to this rule is if the bug ends up killing the product: for example, it causes violent app crashes for a significant number of users. In this case, we will put down our work and resolve the bug as soon as possible.
Ultimately, of course, we can dive a whole lot deeper into this subject. If you are interested in this, you can read Basecamp's Shape Up. Basecamp has introduced the principle of the 6-week cycle and are very generous in explaining their methodology for free. I recommend that you handle their book as you would handle a buffet: pick what applies to your organisation and ignore the rest. If you don't like salmon, don't eat the salmon. In this way, we ultimately came up with an approach that best suits our organisation and culture.
In the end, the 6-week cycle has led to the following advantages for us: our developers are happier in their work, we deliver higher quality product work, and our projects don't last forever.
A Dutch version of this article was previously published on Start24.nl.