In Praise of the Messy Development Cycle

A real-world case

A dev team that I know recently launched a major new release of a client project.

Right after launch, the team responsible for the release started a new development cycle (sprint) on another project. Shortly after however, they were forced to split the team as problems came to light in the software that they just released, and part of the team had to go back and work on it.

When I asked the team why they hadn’t taken a grace period into account, they said there was no budget to keep the team around after launch.

Unfortunately it wasn’t the first time that I heard about this practice.

Why is scheduling cycles back to back a bad thing?

When it comes to feature development, developers need long stretches of uninterrupted time. Development cycles need to be planned carefully. A team split during a cycle means that the schedule needs to be redone, goals need to be revised, and the client needs to be informed of an unwelcome delay.

In addition, these problems are often foreseeable and therefore unnecessary. As a software team that scores below 11 in the Joel Test, which is the vast majority, you know that after a major release of new code, bugs will come your way.

Introducing the ‘messy cycle’

At E-accent, we would alternate focused cycles with “messy” ones.

During focused cycles, the development team (save one) would work on feature development without outside interference.

One developer (on a rotation schedule) would meanwhile deal with other tasks, such as operations tasks, system updates, critical bugs, developing or upgrading in-house tools, etcetera.

Every 6-8 weeks we would schedule a “messy cycle” in which the whole team would take a break from feature development, and focus on the product backlog, dealing with loose ends, and working on improving the workflows in the company.

37signals’ Shape Up framework has a similar feature, which they call the cool-down period.

How to pay for messy cycles

OK that’s all great, you might say, but who pays for those messy cycles?

The answer is, higher profit margins do. Which can only be done by improving quality.

It is an illusion to think that maximum profit is a function of maximising the number of billable hours.

The problem is that, even if you bill by the hour, clients don’t think in hours, but in value. If you build them a $ 30,000 feature, they need to figure out a way to recoup that money, plus a sensible return.

Both you and the client would prefer you to build the feature in 150 hours at $ 200 an hour, instead of in 300 hours at $ 100 an hour. After all, the client would get the feature faster, and get a return faster, while you would get a higher margin.

But how do you get your team to double their productivity? By continuously investing time in improving the quality of your team and development process. If you allow noise into your processes, and don’t invest time in improving your company, you will stay stuck in a hamster wheel, producing mediocre software under high pressure and at low margins.

Therefore as it turns out, messy cycles are not that messy. In fact they are essential for the long-term viability of any software development company.