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.

Core Program Team

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. ...

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.

I've seen this as well, where there's little thought in the "Agile" project delivery and deployment. "It's not our problem once we deliver it to IT. 'They' will deploy whenever..." (No kidding). Deployment is a feature and those involved in it need to be part of the team. We're all one happy company, right? :/