I often find that teams that have adopted Agile practices quickly plateau. They often start by scheduling a daily stand up, planning in iterations, take time for a retrospective, and modify their estimation process. These are common first steps in the agile adoption process. Teams have varied success and commitments to these practices but nevertheless these are the low hanging fruits in the Agile adoption journey.

Once a team has plateaued, where do they go from there? After years of leading Agile software development teams a consistent thread has emerged. Teams should work to create an automated continuous deployment process. I intentionally did not use the word continuous integration(CI). This is not to say that what I’m proposing does not involve continuous integration. However the word has been misused by numerous teams. Many teams that I work with only use their CI build to run a few unit tests. While this is an important first step it fails to address the systemic problem within our industry of integrating our products together.

If your team spends more than an afternoon deploying their product to a test region or to production then you need to start chipping away at this next step. Agile software development emphasizes working software. While this seems like a no-brainer, we often neglect the core issues that prevent our software from working. The most significant one being that we often do not know our software does not work until it is too late.

The single most powerful change that you can bring to your software development team is continuous deployment. What does this mean? I’m not suggesting that you auto deploy to production. I have not worked with an organization yet that is ready to make this leap of faith. Instead I’m encouraging you to:

1. automate your deployment process and run it every time your check in your code.
2. run a couple of user tests that walk through the most common end-to-end flows

While this may seem fairly straight forward this is difficult to complete. Much of this depends on your architecture, infrastructure and policies. To illustrate this point let’s look at a project that I lead a couple of years ago. In order to auto deploy our project and run test against our product we needed:

1. to have admin privileges on 5 dedicated database.
2. to create the database from versioned scripts
3. to load test data in each database
4. to have an application server on our CI box.
5. to have a message queue on our CI box.
6. to have three web services deployed and running
7. to have a build process that can automatically build and deploy an EAR to the application server

Policies, licensing and time are the largest barrier standing in the way of achieving this in any organization. This example may be more or less complex than the needs on your project. Nevertheless, in my experience working to break down these barriers is essential to delivering working software. Being able to address deployment issues as they come up is much less stressful than standing in a cube after hours trying to figure out why this stupid app won’t work with managers asking if you are “done yet”.

Policies can be changed if you track the amount of wasted time as it relates to deployment delays. Licensing costs can be accounted for or avoided (open source) if managers understand the savings. And as far as time goes, I’m more willing to put some time up front so I don’t have to loose my nights and weekends at the end of the project.

I know that this is possible. I have seen it work on numerous projects and team. Take the next step in Agility and automate your deployment process. Ensure that your software works by running a few end-to-end user tests. The effort is worth it. Your time and sanity is worth it.