Agile Deployment - an Oxymoron?
MarianneHollier 060001NFMK Visits (3501)
In traditional software development lifecycles you typically only perform "deployment" once at the end of the project, but with agile you may deploy multiple times in some or even all of your iterations. Deploying incrementally can be a challenge unless you follow some great agile deployment practices. In addition, deploying more frequently can add huge value to your overall solution. Just to get us on the same page, I define "deployment" as ensuring your solution reaches AND is used by the intended end users.
Below are four ideas that can
help you with this challenge.
1. What type of deployment do you have?
All deployments fall into one of four simple categories:
Knowing which type of deployment you have will help you better understand the user stories and subsequent acceptance criteria needed for your deployment. I have found that the deployment-related user stories are frequently overlooked until the end of the project, and then the team scrambles to get the solution to the end users.
A push to users deployment is one where the solution is essentially forced upon the users at a specified date and time. The end users have little or no control as to when the new solution will be made available to them, and they may not want to use the new solution right away. An example of a user story for this type of deployment is "A user can continue to use the current business workflow, even after the new solution is deployed." This user story assumes that the user has the option of using either the newly deployed solution's business workflow, or staying with their current workflow.
A custom install deployment is one where your team takes the solution to a customer site and assists with the install and configuration to meet the customer's needs. A user story for this type of deployment might be "A user can install and configure the solution in less than eight hours." Note that in this story, the “user” is the installer, not the end user. Custom installations typically take much longer than packaged installations, so setting a time limit on how long the installation will take should help the development team streamline the custom install tasks.
A download site deployment is one where you post your solution on either an internal or external web site where users can download and install the solution on their own. An example user story for this type of deployment is "A user can perform the installation directly from the web site, and does not need to download the installation package as a prerequisite to installation." Another variation on the download site deployment is one where the user is prompted to update his or her existing installation, similar to Microsoft Windows Update.
A shrink wrapped deployment is one where you physically ship your solution either directly to users or to retail stores for purchase, and the users install the solution on their own. A user story for this type of deployment might be "A user can customize the following options during installation: language and installation location."
2. Plan your deployment – increments are good!
If you think testing always gets compressed in traditional lifecycles, deployment tends to be even more overlooked and pushed to the very end. This procrastination tends to increase the risk of actually getting the solution to the end users, and getting those folks to use the solution. Many folks think that you have to deploy the solution in one shot – all or nothing – but they are mistaken. In fact, incrementally deploying the solution is much simpler, and reduces the risk of deployment much sooner in the project. The illustration below encourages you to break your deployment into pieces, rather than attempting to deploy everything at one time.On agile projects, you are refining, designing, creating and testing a part of your overall solution in each iteration. Ask yourself (and of course your whole team) – why shouldn't we deploy what we have created at the end of each iteration? Some initial responses might be:
For each of the responses, ask yourself "Why?" I have found that many of the perceived obstacles to deployment are not really that big, and with a bit of work, they can be taken care of quite quickly.
In addition, if you follow one of the key agile principles "Working software is the primary measure of progress" you should be creating fully working and tested increments of your solution. If you are not really yet creating "shippable" or "production ready" increments, deploying incrementally (or at least asking why you can’t) will encourage you to do so.
3. What goes into each deployment increment and what is the risk?
Another challenge to overcome is "what should we deploy and when?" Just because you created something in the current iteration does not mean that you have to deploy THAT piece of the solution at the end of the iteration. You can pick and choose your solution parts if you have architected the solution well, and have a good configuration management strategy. It is important to give your users a part of the overall solution where the collective parts provide overall value.
I also encourage you to consider the risk of deploying what you created in the iteration against the risk of NOT deploying it. For example, say you were creating a brand new repository where sales folks could capture all their customer interaction information, and they currently do not have a single place for that information – it is scattered about in spreadsheets, emails, sticky notes, etc. Would it be better to deploy the repository with only the ability to create and modify a subset of customer information now, or wait until all the functionality is there? The risk of delaying deployment is that the sales folks get tired of waiting, and cancel the project to fund some other new shiny project. The risk of deploying a subset is that the sales folks want more functionality (hey, is that a risk or a benefit?). In my experience, I have found that the sooner real users can get their hands on the solution, the happier they are, and the better the final solution will be.
4. To beta test or not to beta test?
In many organizations the term "beta test" is considered a four-letter word. However, if expectations are set, this activity can be an invaluable learning experience, for both the end users and the development team.
I define "beta test" as a subset of your overall user acceptance testing efforts, where user acceptance testing is typically the only testing that is performed by real users. There are three types of user acceptance test:
All of these types of user acceptance testing can happen in ANY iteration – not just at the end of the project. The sooner you get even a part of your solution into real users' hands, the sooner you will know if any course corrections need to be made.
The only rule that I have about user acceptance testing is that you MUST capture the user feedback. The formality in which you capture feedback from your users is up to you – you can sit with them and write down notes of good and bad things, you can have them log tickets with questions, issues, defects, new requirements, etc., or some other mechanism.
Regardless of the type of deployment you have, getting feedback from real users can be game changing. Features that the team thought were just average might be seen as absolutely essential by the end users, and vice versa. Even with a product owner engaged with your team on a daily basis, having other real users exercise the solution will uncover new and exciting solution ideas. Remember that agile is about creating the highest value solution, not one that “meets the documented requirements”. This feedback is vital to creating that high value solution.
In an agile lifecycle, I encourage you to conduct user acceptance test in one or more ways listed above, and perform this testing early and often. Also, try to keep in mind that you are embracing user feedback – good or bad – so that you can improve the overall solution. Select a subset of open-minded users – the ones that want to help you make the solution better. I can not stress enough how IMPORTANT this is.
In conclusion, I strongly recommend that you focus on the following items to help you with your agile deployment:
If you implement one or more of these items on your project, I can almost guarantee that you will deliver increased value and quality of solution to your end users.
Note: For more details on these
deployment and other agile practices consider acquiring the IBM Rational Practice
library using Rational Method
Composer. If you already use Rational Method
Composer, you can download the practice library at: http
Author: Marianne Hollier, IBM Rational Senior Managing Consultant, email@example.com
Editor: Anthony Crain, IBM Agile Transformation Specialist, firstname.lastname@example.org