Which Delivery Option Is Right for Your New Agile Program?
With agile, you have delivery model options you didn’t have before. There is no hands-down best model. What you choose should depend on what your team and your customers need.
With continuous deployment, you deploy as you have features ready. You need to have continuous integration across all the project teams, or you need to somehow manage the risk of not having the code integrated. You need enough test automation to know the product will not blow up so you can continue to deploy new features and not break old features.
Some people get concerned: What if they deliver the wrong features first with continuous deployment? Here's where you need a roadmap. Who is updating the roadmap? And how often? How long are the iterations?
The more you work toward continuous deployment internally, the more your program product owner can see the value of your work. That means the faster the program can potentially be over. It’s worth trying.
In phased deployment, you can commit to certain features on the roadmap at certain times to the customer. You deliver builds at certain days and give yourself enough time to test those builds after you complete the features.
One team I worked with was doing hardening sprints, and I asked if they were planning on being able to integrate testing into the development sprints. They tried to give me a song and dance about how testing was integrated. I explained that if they had hardening sprints now—only eight weeks into the program—testing was not integrated. It was only going to get worse the more people they added and the longer they proceeded. Did they know and understand their impediments? It’s one thing to make your release decisions because it’s a business decision. It’s another because you can’t choose one of the options.
All of the program product owner’s decisions are magnified when they roll down to the feature teams. If you have ten teams, that’s one thing. If you have thirty teams, that’s even more magnification. If you decide to de-emphasize technical debt and the technical teams don’t address the debt when they create the features, you might be left with code that doesn’t always compile—never mind release.
When you start a program, think about how you want to deliver. There is no one right answer. Continuous deployment might be right for you and your customers. Your customers might say, “No, we do not want the system to change all the time,” but you might decide you want the discipline of being able to release at any given moment. In that case, continuous deployment internally might be exactly the right model.
Phased deployment is a great alternative if you have a roadmap and you know when you want to commit to which features on your roadmap. You want to pick your customers and work with those customers carefully. When I managed beta programs and worked with beta customers, I set their expectations about what they would get in each beta release. It’s the same idea, except you want to have many more deployments.
If you have to stick with a traditional rollout because you have hardware or some other constraint, you’ll have to work to make your product appealing. You won’t have the work-in-progress updates as enticement.
If you want to be agile in your program, you need to think about delivery and deployment as soon as you start your program management work. How you deliver and release is critical. Once you know your release criteria, you need to know how you will release. There is no right or wrong decision. It’s a decision for your program.
