Agile in name only

Agile isn't agile if you end up going over a waterfall at the end.

In politics, the term RINO is used to refer to a candidate who is “Republican in Name Only,” i.e., claiming the mantle of the party, but not conforming to the platform or belief system. In software development, there’s a similar phenomenon: companies that claim to embrace agile development principles, but really don’t understand agile. They’re Agile in Name Only (AINO).

I’ve written before about “waterfall with a crunchy agile shell,” the problem that if you are trying to control all three of the variables (time, features, resources), you can’t really do agile. Agile acknowledges the uncertainty in development estimates, and requires the team to stay “ready to ship,” so that when the decision is made to pull the trigger on a release, all the work done to date can be easily consolidated and shipped. But focusing on keeping shippable units in shippable shape only makes sense if you also embrace the idea of frequent releases, and putting only in the release what fits in the bucket.

In contrast, a company that’s agile in name only will cling to a distant release date and a laundry list of features, but still insist on short sprints and closing stories. At this point, the benefit of short sprints isn’t for the developers or the team, it’s for management, because it lets them focus on their burn-down charts, and chart the progress toward that eventual release that may be a year away.

A short sprint (two or three weeks) comes with a lot of overhead meetings, including grooming, planning, retrospectives, etc. But worse, it requires the developers to divide up headlines into stories that can fit into that sprint size, even if it makes no sense. It encourages multiple coders to work on a single feature, because the idea of a single developer seeing a headline through from start to finish doesn’t fit into this model.

Agile makes huge sense in environments like mobile and cloud-based applications, where the ability to force a release out to the user base frequently with full adoption is possible, and where the cost to push out a release is relatively low. But in a situation where releases only come out once or twice a year, agile starts to lose its benefits. It doesn’t matter that the code you just wrote is ready to ship, because you’re not going to ship it. And you’re going to develop another dozen features before the new release does ship, leading to doubt that your feature is still shippable, and a subsequent long tail for the release.

TDD is obviously a way to attack the long tail, by ensuring that you haven’t broken things, but the bigger problem is that AINO indicates that a company is embracing a project management approach without really understanding why they are doing the things they’re doing. Agile without frequent releases loses much of its value, and it typically indicates a company that isn’t going to really follow through on other tenets of agile, like insisting that stakeholders (the people who are supposed to have the best understanding of the product needs) attend meetings.

It would be great if there was a way to incorporate the benefits of agile into companies that require infrequent releases, and if anyone is working at a place that has managed to make it work, I’d love to hear about how it can be done. Tell me about your experiences in the comments, please!