I hope that this 3-part series on how to move to continuous integration and how to evaluate if it’s worth moving to continuous integration on your program convinced you moving to continuous integration was worth it for programs.
The reason continuous integration is an issue on programs, is because the lack of CI can delay the technical program. That, in turn, can delay the overall program. That affects the project portfolio and often delays the start of other projects or programs. It reinforces the feelings of “we have these sunk costs so we’ll keep sinking more money even though we can’t tell what we’ve done.”
I feel as if I’m saying when a butterfly flaps it’s wings over here, the world changes over there.
It does.
It’s easier to see in a smaller organization with one 3-team program. Of course, it’s easier to make continuous integration work on a 3-team program. It’s not so bad on a 4-8 team program. It can be horrendously difficult on a 37-team program, especially a program that’s new to agile. That’s why I don’t recommend people start their transition to agile on a large program.
This is one of the reasons program managers often make project portfolio decisions. They have the data the project portfolio managers do not. The program managers are face-to-face with the people who are saying, “One more month, and we’ll have a demo for you.” Even though those people have said this for the past four, five, six months. If those people had continuous integration, they would have had a demo already.
If you do not have continuous integration on your program, make sure you do have incremental funding. Otherwise, you have no way to do project portfolio management and call a stop to the program. Well, you do have a way, but it’s difficult. But if you have to go back for more money, that’s a great way to force the technical program to have to prove that they have something to show for their efforts —a demo, an interim deliverable, a something. Incremental funding means no one runs open loop.
Continuous integration is a form of risk management for all programs. I don’t see how you live without it for agile programs. And, if you want to take an agile approach to the project portfolio, you have to have at least regular deliverables for your projects and programs. Otherwise, the people on the projects feel as if you are yanking them around for no good reason.
The larger the project, as in programs, the more the technical practices matter. Not because the code demands it; code doesn’t demand anything. People need the structure that the technical practices provide.
But the people need the technical practices on their own terms. A program manager can’t impose technical practices such as continuous integration. A program manager can offer the practice and suggest ways it can work. A program manager can ask for the result, and wait to see how the teams want to implement the practice to achieve the result. That’s what it means to be self-organizing or self-managing teams.
Communities of practice can assist with these practices. It’s messy. It’s not top-down. It might take a few iterations to get right. That’s ok. Everyone will live with it, and then because the teams will have decided how it will work, they will proceed smoothly.
And, once you have the technical practices so that the program flows smoothly, the project portfolio work will flow smoothly, assuming you have people willing and able to make decisions. That’s fodder for another post.
