Why Elegant Code doesn't get Agile

This blog post seems to insinuate that Agile does not work. I believe that their David Starr (correction: I directed this at all of Elegant Code when I should have been specific to the poster. Apologies for this oversight on my part) conclusions are flawed and that they truly don't understand that Agile is an idea and not a process. I think a better title of this post would be "why being dogmatic about Agile doesn't really work" or "why people who do things because that's what you do in Scrum doesn't really work" or some such. By making this blanket statement about Agile not working, they are both ignoring the many success stories that Agile has and betraying their own ignorance of the Agile process.
"Agile supports the idea of frequent delivery of value to customers."

Let's look at shipping software for a minute. Where in the Agile Manifesto does it say "You have to ship software every two weeks" or anything like that? Go ahead, look for it. I'll wait. Didn't find it? That's because it isn't there, and it isn't there for a reason. That reason (I generally believe) is that shipping software to customers every two weeks is a retarded-stupid idea for all of the reasons that the article goes into. I'll summarize them here:

• Sales can't keep up with that release cycle
• Training can't keep up with that release cycle
• Documentation is often not available at that frequency

I'll even add a few more:

• Any type of release-preparation can't be done (burning CD's, peer-review, post-mortems, etc)
• Software with a high amount of overhead to upgrade won't allow for this (think SAP or Sharepoint or some such product)
• Most customers don't want a new version every two weeks because they'll have to upgrade and re-train their employees
• This pace is not sustainable, which is something that is, in fact, on the Agile Manifesto ("Agile process promote sustainable development")

So what's the point? In Agile, we recognize that working software is the best measure of productivity. We also recognize that we want to deliver working software as frequently as possible. This brings us to:

DELIVERING WORKING SOFTWARE IS NOT THE SAME AS SHIPPING A PRODUCT!!!!!!!!!!!!!!!!!

That's right, you can deliver working code constantly. You can deliver it to sales so that they can preview what they're going to sell. You can deliver it to your customer proxy to verify that you have correctly implemented the features that you need. You can deliver it to your sprint demo so that the rest of the world can see it work and know that you're going well. You can deliver it to your project manager so that he doesn't have a heart attack every sprint because the software doesn't work. BUT YOU DON'T HAVE TO SHIP IT. Just because you CAN ship something doesn't mean that you should.

So why do we deliver working code in the first place if we're not going to ship it?

Because in Agile, we want rapid feedback. It is much, much easier to fix something right after you build it than it is to fix it three months after you build it. The sooner you know that you need to change something, the easier it is. For example, let's say that your QA department is one sprint behind your development in their testing. On my team, we average about ten builds per day (utilizing our CI tools at the time of checkin, but if you count personal builds it's probably a lot more). Our sprint is three weeks, which gives us about 14 days of development on average (adjusted for the time spent on code review, sprint planning, sprint demos, holidays, etc.). With ten builds per day, that means at a minimum, QA is finding a bug that has existed for 140 builds. Other functionality may be built on top of it. It may have dependencies on other parts of your code. Finally, where the hell is that bug occurring, given that maybe you've worked on a dozen different objects since the bug was introduced? You'll have to hunt for it, and that takes time.

So Elegant Code has missed the boat on this one: They're assuming that delivering working software means "shipping it to the customer" when this is absolutely not the case. They're jumping to that conclusion. Maybe I should write "delivering software means shipping it to the customer" on a mat on the floor, and they could "jump" to it. I'll make a million dollars!

"[The] organization [you're shipping to] must actually be able to receive the update without tipping over"

This is their second argument against Agile, and (coincidentally enough) their second mistake. I've added some words to clarify their point so that it isn't taken out of context, but I would encourage you to read the article so that you don't think I'm making this up. That is not my intent. Anyway, we aren't shipping the software every two weeks, so the customer only gets their release when they actually want it. The strength of Agile is twofold on this:

1. We can show them what they're going to get more easily because the software is always working. We can give them a beta whenever they're ready for it so they can start coding against our API if they want to. If they don't like our API, we can change it easily and ship a new version. They can see if the features they want are actually going to work the way they want. They can give us rapid feedback, which is very important to our ability to deliver them the features that they want.
   
2. We don't have to ship it to them "on time" either, because when you can ship every two weeks, "on time" starts to mean whatever you want it to mean. If they aren't ready for a month or two, we can delay and continue to add value (or just branch the code) and ship when they're ready to receive. If they suddenly get an upgrade to their database and our code is going to break it if we add Oracle support, we can release a working version prior to adding Oracle support. BizTalk no longer supports a feature? Prioritize that as a sprint item and ship two weeks later. Try doing that in waterfall.

In short, we gain a lot of flexibility over when we can ship. Again they're leaping to a conclusion (maybe two spaces on the mat and they can "jump" to both "conclusions") that they have to ship and it'll cause all kinds of problems for the customer if they do. In fact, the opposite is true: because you can ship at any time, you have the flexibility to deliver value whenever it is best for the customer. If you force them to upgrade, that's really an anti-pattern that I call "shoving functionality down their throats until they choke on it." This is never good.

In fact, the problems that they describe are actually readily solved by Agility: Documentation team needs another week or two? No problem. At least we have a working piece of software for them to document against. We either add something small that they can easily document, refactor the code against our //TODO list, or branch and keep going with the intent to release a branch. IT says you need a week-long burn in test? Or what about a month long peer-review process like my company? Not a problem either, we just branch and continue working on the trunk, fixing anything that comes up in the branch (which is what we're releasing) and merge those fixes with the trunk one at a time as soon as they're finished so that integration is easier.

Ultimately, Elegant Code David Starr has not missed the boat, but unfortunately the boat that they caught was the failboat. Their argument sounds good on the surface, but they have failed to realize that Agile's ability to handle change combined with a rapid feedback cycle actually deals quite nicely with all the problems that they are describing. I'd like to close with a question: If Agile doesn't work, what does? Huh? Can't find that in the article? It's in the same place in the article as "shipping software" is in the Agile Manifesto (i.e. it's not there). I think Elegant Code needs to do some more studying on what Agile is and what it truly means, as well as looking at some success and failure stories before they suggest that Agile has failed because you can ship too frequently if you're dogmatic about it.