I like continuous integration. A lot. I started being an aficionado of continuous integration back in my senior year of university . It was my very first (and last) team project in my college career. There were three of us. The project manager waited until the night before the project was due to get us all together (argh #1). I had completed much of my code several weeks before (argh #2: who can remember what they’d written several weeks ago?). We wrote code madly for hours, and then tried to make it work, starting about 9pm. It didn’t work. We stayed up all night (argh #3). I finally went back to my dorm about 7am so I could shower and eat breakfast for my 8am class. The other two guys blamed me for leaving, saying I should stay with them. I explained nothing had worked yet, nothing was going to work if I went to my other classes (just about the only smart thing I’d said all night).
That’s the night I realized that if you don’t start putting software together a little bit at a time from the beginning it gets harder the more you have to put it together. I’ve been a fan of continuous integration ever since.
I am sure there are projects where continuous integration might not be the answer, and I have not met them yet. And, 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, so you can see what is so difficult 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. Have pity on these people. Do you want to make them suffer?”
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 you are.
What Does Continuous Integration Mean to You?
The first question is this: What does CI mean to you? To me, it means that the software is Done. That is, it is compiled, tested, and not just demoable, 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 strawman proposal of what done means, and see if the feature teams can live with it. Then, the feature teams should test that strawman for a limited time, such as an iteration, and see if that proposal makes sense to them. If you’re working in kanban, set a time period, such as one 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?
The first step is to know where you are.
The ideal case: Are you finishing features every iteration, as often as every day or so? You are likely doing continuous integration across your program.
Finishing Stories All the End of an Iteration
What I see in many teams practicing agile: Are you finishing 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 makes for staged integration in a program if all the feature teams do this.
What I see in some teams quite new to agile: Do your features span iterations? If your features span iterations, you need to make your features smaller. The reason to make your features smaller has nothing to do with continuous integration yet. Making features smaller is all about seeing your progress and providing feedback to the product owner/customer and making sure you actually complete work inside the iteration. If you are using kanban, this is similar to seeing a board not change for weeks while the same features are still on the board, nothing moving. You are also likely doing staged integration.
If some of your feature teams do one thing, some of your feature teams do something else and you need a way to merge them all together. When I work with program teams, I find the teams doing some of each of these. And, the waterfall teams are doing something else entirely. On a program, we need a way to bring the entire product together on a periodic basis.
Stay tuned for part 2.
