"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
- 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")
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:
- 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.
- 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 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.