One of my program management clients is organizing a program and is having trouble thinking about a delivery model that fits their program. They are transitioning to agile and are accustomed to traditional releases.
When I suggested they have someone representing deployment on their core team, that was an initial shock to their system, and now they see that it was a good idea. They don’t have a hardware person on their core team, but otherwise they look a lot this this picture.
With agile, they have options they didn’t have before. Because they are a software-only product, they have the option to release as mandated release as before. They can rollout as before, with IT scheduling the release and mandating when people upgrade. I asked how well that worked before. You should have seen people’s eyes roll when I asked that question!
I suggested there might be other options: continuous deployment and phased deployment. With continuous deployment, you deploy as you have features ready. You do 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.
Remember, a program is big. Imagine you have at least 50 people, working on this program. This client expects to have closer to 150 at full staffing. (I think that agile approaches will mean they will need fewer people, but that’s my opinion only. No data yet.) If you have 5-7 person cross-functional teams, all checking in completed features every day or two or three, and everyone is verifying that yes, their code works against the main branch, you have a lot of progress being made every single day. Every day. 50 people is only 10 teams. That’s it. 150 people is 30 teams. Talk about a program taking on a life of its own! You can’t “control” that. You can guide it.
Some people were concerned—what if they delivered the wrong features first with continuous deployment? I asked about their roadmap. Who was updating the roadmap and how often? How long were the iterations? Remember Short is Beautiful? I had a chance to explain that again.
Then we discussed phased deployment, where they could commit to certain features on the roadmap at certain times to the customer. They could deliver builds at certain days and give themselves enough time to test those builds after they had completed the features. I asked if they were doing hardening sprints now. They sheepishly said yes, they were. I said that was fine, as long as they knew what they were doing. I believe in being honest with yourself. 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 8 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 decisions. It’s another because you can’t choose one of the options.
It turns out the program product owner had a bad case of feature-itis. This can be a disaster for a program. All of the program product owner’s decisions are magnified, because those decisions are rolled down to the feature teams. If you have 10 teams that’s one thing. If you have 30 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. As Covey said, “Start with the end in mind.” There is no one right answer. Continuous deployment might be right for you and your customers. It might not. Your customers might say, “No, we do not want the system to change all the time. Stop it!” However, you might decide that 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. A gazillion years ago, 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 you have some other constraint, you’ll have to work to make your product enticing. You won’t have the work-in-progress as enticement.
The more you work towards 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.
What clear to me, is that 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.
Reference: Agile Program Management: How Will You Deliver? from our JCG partner Johanna Rothman at the Managing Product Development blog.
