Do less to do more

Here's a little story. I'm sure you've seen this before, so I'm telling you nothing new. But it was on my mind, so I wrote it down...

At the beginning, you have the best of intentions. You know what the 12 rules are, so you're going to be agile. You're going to release early, and release often. You're going to use time boxing, so you keep your sprints short. You've established your personas and used them to write user stories. You know you need to deliver working software, so you publish a release train schedule, and hold your daily stand up meetings and include test driven development as part of your practice of continuous integration.

So far, so wonderful. There is not a thing wrong with any of this; these are best practices for a reason, and you do indeed have the best of intentions.

But as time goes on, little things occur.

A developer hits a bit of a speed bump and her estimated 3 day effort leaks into the 4th day. The build team are struggling with new tools, and the builds aren't immediately available. Automating the tests is turning out to be challenging for the testers, and sysadmin has struggled to deliver the VMs because of a vendor slip. The first several sprints have gone well, but a few bugs linger from the early releases. And, having finally had some hands-on time with working software, the product managers have re-thought the requirements, and the stories for the sprint that you've just begun are no longer seen as the most critical.

You make a fateful decision: you decide that if you just expand this sprint from two weeks to three, everyone will be able to catch up.

And it seems to work! Some extra bugs get fixed, a few more tests are written, the builds are being delivered more reliably, and, best of all, the developers found the time to react to product management's requests and were able to fit a few more features into this release.

But then, it happens again: the next sprint starts with its two week schedule, but on the fourth day you realize that, once again, a few things are cropping up, and oh, couldn't we just make this release a three week sprint as well?

After a few iterations, the three week sprints seem to be successful, but it's been confusing, as the team members are no longer sure whether they're working on a two week schedule or a three week schedule. The product managers and the developers are starting to figure out ways to fill up the time, adding larger projects to the plan, and you can hear new words in the hallway discussions: people are differentiating between "core" stories, "optional" stories, and "stretch goals". When you ask them what's going on, someone says:

Well, the schedules keep slipping, so to keep everyone fully occupied we've added a few extra optional stories into this sprint. We know we may not get to them, but if it turns out that somebody has time near the end of the sprint, they can pick up one of these projects and fit it in.

It seems like a reasonable request, and so you let it go.

But then, just as the sprint is supposed to be ending, on the next-to-last stand-up, one of the developers pipes up and says:

I thought I had enough time, so I've started on this story, and I've almost got it done. In fact, I've checked in some early code, so that's why those tests are failing. But I won't be done tomorrow, because it's a bit more complicated than we thought it would be. I just need two more days to finish, so let's slip this sprint until next Tuesday.

What are you going to do? Of course the slip is granted. Three week sprints weren't the end of the world; surely a four week sprint isn't going to kill us?

But soon you find yourself neck-deep in trouble: sprints are taking 4, 5, even 6 or more weeks. Predictability is gone, and confusion is rampant. You know it's reaching a climax when upper management convenes a two-day offsite with the topic: "How do we regain control of our development process."

What went wrong?

I think there are two basic issues here:

1. Firstly, there is a fairly simple feedback loop in effect here: the more you try to do, the longer each incremental cycle takes. But the longer each cycle takes, the more you try to do, as your staff automatically compensate for the longer cycles by embarking on more and larger projects. Moreover, one of the major reasons for having extremely short increments is to minimize the impact of estimation errors. As projects get larger, our ability to accurately estimate their size and difficulty drops dramatically, leading almost inevitably to schedule slippage as cycle sizes grow.
2. Secondly, and perhaps without your realizing it, you have been sending a message to your staff that "schedules don't matter." There are many different aspects you can prioritize in a software project: features, reliability, usability, performance, budget, timeliness, etc. Since you get what you reward, it should be little surprise that as you've been favoring things like features and budget over schedule, your team is reacting to that by paying less attention to the schedule and more attention to those things that you are rewarding.

So what can you do?

I think there's really only one answer:

Do less to do more

Agile processes can be very effective at controlling runaway development costs, and at coordinating teams working on complex problems with great uncertainty, which commonly arise during software development.

But you have to stay disciplined! Continually emphasize to your team that it is critical to keep each sprint small and contained, and that you'd prefer to omit a feature than to slip the sprint end date.

Keep the focus on small, easily understood user stories, operational features, and continually executing test suites, and your agile methods will bring you success.