Try an Agile deployment strategy
Agile development methods hold value for more than planning, design, development and testing. A deployment strategy also benefits from Agile tactics.
Does it seem like the term Agile is being tossed around wherever you look these days? Some IT developers seem to eat, sleep and breathe Agile. They probably even do multiple build and test iterations with their sandwich order at Quiznos, driving the employees there crazy. Still, you don't have to be an Agile fanatic to admit that the method has many useful features in the field of software project management. It's not just for planning, design, development and testing either. Deployment strategy can also benefit from Agile tactics. Here are some tips that can help when you do your next Agile deployment.
Agile requires automation
In the real world, Agile users often focus mostly on speeding up the time to deployment and deploying more frequently. The actual process of deployment may be ignored. That can be a huge headache for the operations side of IT. They are the ones stuck with trying to deploy one new version after another, often rushing (and increasing the risk of errors) because there's a gigantic backlog to deal with.
There's nothing Agile about getting an application all ready to go and then realizing it won't work with the equipment in place on the production side.
There is little benefit to developing a product in a week instead of a month if it sits on the "launching pad" for several weeks in operations. That's why operations must be provided with the tools to automate frequently recurring deployment activities. Fortunately, subsequent Agile iterations are usually similar to previous versions, which means there is a high potential for reuse in everything from batch scripts to installation scripts. Ideally, operations should be able to focus most of its energy and brainpower on major production releases.
Lock and load
If you do weekly deployments, having the development and deployment teams on a set schedule can be very beneficial. IBM describes its process for reducing cycle times through the introduction of time-boxed iterations for the deployment team. Development is expected to provide code by 9 a.m. each Monday. The deployment team would spend Monday to Thursday deploying (first to staging, then to production). Development knew exactly how much deployment resources were allotted to the project and could determine what was most important to have deployed each week. This helped them focus their efforts effectively and prepare deployment packages accordingly.
Continuous Agile deployment
Agile deployment may be seen as simply another testing step since multiple development deployments are performed between production deployments. QA "users" are deeply involved in improving the system by providing frequent feedback. These are not system or organization-wide deployments. The code is deployed to a QA or testing environment that is accessible to specific users and as close as possible to a real-world environment. That way, users can continuously test the software and send it back for improvement. In some cases, patches may actually be added in the production environment. Or, the product may be sent back for more iterations in development. And, sometimes, pilot or beta deployment to a limited number of end users in the final environment may also be done for even greater insight into real-world usage.
Look forward to production
Since your software is only as relevant as the real-world systems available to run it, you should consider the production environment when you are planning and developing the software. This helps avoid embarrassing missteps during deployment. There's nothing Agile about getting an application all ready to go and then realizing it won't work with the equipment in place on the production side.
Document at long last
With Agile, it can be hard to know what the end product is going to look like until you actually get to the release stage. That means doing a lot of documentation up front is foolhardy -- you'll have to redo most of it. So, do just enough documentation during development to keep everything organized and on track. Then have the detailed, accurate version of documentation done as part of the finalization process. Ideally, you should document the deployment process, support procedures and user instructions as well. This is an area where development, operations and support may need to work together to ensure accuracy and usefulness. With an Agile deployment, you only do as much documentation as your stakeholders want.
It ain't over yet
In the Agile world, deployment is hardly ever final. It's viewed as a process. Even if you tend to do more traditional waterfall-style software project management, this can be a useful attitude to adopt. You still test and test, but you know that not everything has to be absolutely perfect prior to the Go Live date. A problem here or there is not viewed as failure. Use the feedback you gain as a way to improve and deploy a better version in short order. Just be prepared to actually follow through and make those improvements; Agile should never be used as an excuse for shoddy work.
