The Cost of Continuous Integration Is Well Worth the Time
If you don’t start putting software together a little bit at a time from the beginning, it gets harder the farther along you go. I am sure there are projects where continuous integration might not be the answer, but I have not met them yet. However, I admit there are times when the cost of continuous integration seems pretty high.
The agilist in me says, “Do it more often. That way you see what the impediments are and you can make it easier every time you do it.” The pragmatist in me says, “Not everyone knows how to do it more often.”
I don’t want to make people suffer. I do want people to realize that continuous integration is often well worth their time, even on a large program. So, here are some steps to help you move to more continuous integration, depending on where your team is.
What Does Continuous Integration Mean to You?
The first question is "What does continuous integration mean to you?" To me, it means that the software is done—compiled, tested, and not just demo-able, but releaseable.
Now, it doesn’t have to mean that to you, and it certainly doesn’t have to mean that on a program (especially on a large program). But you should know what continuous integration means on your program, and you should know who decides.
On a program, I recommend that a technical program manager suggest a straw man proposal of what done means and see if the feature teams can live with it. Then, the feature teams should test that straw man for a limited time, such as an iteration, and say whether that proposal makes sense to them. If you’re working in kanban, set a time period of about a week or two to make sure you see some features flow through the system and see if the proposal makes sense.
Now everyone knows what done means for the program, so you know what continuous integration can mean.
Where Are You in Your Journey to Continuous Integration and Agile?
Ideally, you're finishing features every iteration, as often as every day or so. If that's the case, you are likely doing continuous integration across your program.
What happens for many teams practicing agile is they complete features in a hockey stick, with most of the features finishing at the end of the iteration. This is tricky and leads to staged integration, and it can make for staged integration for an entire program if all the feature teams do this.
If your features span iterations, as they sometimes do for teams new to agile, you need to make your features smaller. It has nothing to do with continuous integration yet. Making features smaller is all about seeing your progress, providing feedback to the product owner or customer, and making sure you complete work inside the iteration.
On a program, we need to bring the entire product together on a periodic basis.
