My last two posts have both had the word "dodeca-thalon" in the first paragraph. Dodecathalon means a series of 12 things. Those 12 things are the 12 Agile Principles. So far I've covered the first two. If you haven't read them, please do. And then, read this one, #3.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

As I mentioned with the last principle, we welcome change. We count on change happening, and we use it, Judo-style, to our advantage. But, part of the success to navigating change is feedback. You need quick feedback. And, when you're developing software, feedback comes from delivery.

In my last post, I used the example of a project whose requirements changed midstream, and as a result, was able to be delivered under time and under budget. The requirements were able to be changed because the software was delivered throughout the project.

"They add the recipient selection feature, which takes a day, and then the notes feature, which also takes a day. Of course, they've deployed the entire project for your verification after each of these steps"

This demonstrates two other advantage of frequent deliveries.

1. Verification
2. Usage

Verification

Although I manage the Agile team at Cloudspace, I spend most of my time writing code. I will tell you from experience that the best time to verify that something was done correctly is right after the developer has finished the ticket. Even with well-written and documented code, the benefit of having that portion of the system fresh in the developer's mind saves you on restart/context switch costs, however small they may be. Frequent deployment lets you verify changes during this golden period. I've heard of some clients verifying a feature months (even years!) after the code was written -- it's not pretty. If you're paying for the development work, you want to verify things ASAP.

Usage

Let's say your development team finishes the login/registration system on an internal company app first. Great! Now you're free to go ahead and create accounts for everyone at your company. You've got to do it anyways; may as well do it in parallel with development. The same number of man-hours will be used, but the system will overall be usable in less calendar-hours. Plus, by using that part of the system, *you're verifying that it works!* Awesome! You know it will make sense and work for the end user. Can't do that if the code is sitting on a development server or in a version control system.

At Cloudspace, we facilitate frequent delivery by starting with existing base functionality, and deploying to a production server as soon as possible in the app lifecycle -- usually within the first two days. Even if you don't have a domain ready, we make sure you're able to start moving through the app; I've even gone so far as to point a personal domain at a client's project so that they could start playing around. We've also got custom deployment scripts to make sure that the process is easy and painless for our developers. Given the frequency of deployment, anything more than a single command is too much friction.

So, I think I've given a few compelling reasons for frequent deployment being a good thing. The time and money savings are direct, and as a consequence of fast verification, you'll notice bugs or user experience issues very quickly. This translates into happier users, and more success for your project.

If you've had success stories as a result of continuous delivery of working software, or if you think I'm full of hot air, I'm interested to read your thoughts in the comments. Fire away!

Keep an eye out for the next post in the series, where I explain why business people should talk with the developers. Don't be scared of their non-existent tans, or the fact that they work in darkened offices. Developers are your friends!