An agile-ready checklist

If you aren’t in a position to deploy working code on a regular schedule, then your project can’t really be called “agile.” Getting the team together regularly and taking a test-first approach to development are fantastic practices, and employing them is crucial to a successful agile team. Agile by definition, however, means being able to deploy recent updates to production frequently and regularly.

“Agile” is a bit of a buzzword these days, and one of the chief complaints I hear from developers working towards an agile methodology is the push to be immediately more productive while the infrastructure lags behind. Maybe the development and pre-prod environments are unstable, the process for deploying to production is slow or costly, or there isn’t an accepted standard for driving automated unit and acceptance tests. Whatever it is that’s slowing you down, fix it! The longer it waits, the worse it gets. Here’s my own checklist for deciding whether or not a project is ready to be called “agile.”

Development and pre-prod environments are up and stable

You would think this would be obvious, but I’ve worked on more than a few projects where the team and product owners were too excited to think about where it would live until they were ready to take it live. Depending on the size and structure of your organization, getting a production environment can be a lengthy process. I’ve seen production set-ups delayed for weeks because the request was given to IT during a maintenance period. Oops.

An automated deployment task is in place

Ideally deployment to production should happen at the press of a button. At my company we use AnthillPro, but there are plenty of other deployment tools out there. The point? Make the process of shipping code as fast and painless as possible, so you don’t ever have an excuse not to go live.

Automated testing is also in place

Automated deployment and automated testing go hand-in-hand. Your unit and acceptance tests are your primary line of defense against production bugs, and just like deployment you want this process to be repeatable and as painless as it can be.

Please don’t misunderstand — I’m not saying that you must have 100% code coverage before you go live for the first time. But having a system in place makes writing them that much easier. Most Java projects incorporate JUnit test suite, which is incredibly easy to integrate with ANT. Acceptance testing can be trickier if you aren’t already familiar with it. If your project sits behind authentication, then you may need to write a custom framework to bypass it.

Happy, productive developers

With the infrastructure taken care of up front, developers can spend more time focusing on the next big feature and less time worrying about the development tools. When working code gets released, everyone feels good — that should be all the reason you ever need to want to do it as often as possible.