The teams have determined their individual impediments to Continuous Integration. You, as the technical program manager, and the technical program team can take those impediments, with input from the teams can see the impediments to program-wide continuous integration. You have used a similar problem-solving approach, including the rule of three (which I learned from Jerry Weinberg ) to generate some options for your problem solving. This is where it can get really expensive, because this is where you may need servers and build engineers. And, this is where you are going to start to see significant value, because this is where your program can start to come together every day, where you can get to releaseable product on a daily basis.
Once you do this, you may discover you have insufficient automated tests for your code. (You’ll uncover the next problem down the stack.) You may ask, “Is it still worth doing continuous integration?” I say, “Yes! Write more automated smoke tests as you write code.” But that’s just me. As with everything, your mileage will vary.
As a program manager, you can go back to your project pyramid and go back to the program charter, and go back to the tradeoffs you were supposed to discuss at the beginning of the program with the core program manager. Without continuous integration and the automated tests, you’ll be extending the time to release and possibly increasing the defects at release. With continuous integration, you may need to pay more to reduce the time to release and reducing the defects to get to release—or making it possible to release.
This is why I find the pyramid so helpful in having these discussions. You may need to show cumulative flow diagrams to explain your point. I especially like these cumulative flow diagrams that show features in integration. (You can do that if you use kanban.)
Now, let’s explore some paths I have seen programs use to move from staged integration to continuous integration.
Move From Staged Integration to Release Trains
If you are doing staged integration now, where you have a team of people integrating the software now, consider moving to a quarterly release train approach. Depending on how you implement release trains, you might be agile.
No matter how you implement release trains, every quarter, you integrate and have working product. That much is clear. So, at least four times a year, you have an entire product working in your program. The real question is how long does the product stay working? What is the cost of keeping the product working worth to you? (I don’t know, I’m asking.)
Move From Quarterly Release Trains to Monthly Release Trains
If you already have quarterly release trains, you know what it takes you to integrate the software every quarter. Are you stopping development every quarter to integrate for a few days to a week? If so, consider moving to a monthly train.
If it only costs you a few days, your cost of continuous integration is relatively low, and moving to monthly release trains is likely to be low. I would ask the teams if they can move to monthly release trains. This is where practicing to make the cost low and discovering the impediments to moving to real continuous integration is worth it.
This is still staged integration, but it’s reducing the staging time, and getting you ready for continuous integration. You might want to consider this if you are waiting for servers or build engineers, or other machines or people or