Is the Cost of Continuous Integration Worth the Value on Your Program?, Part 1

[article]
Summary:

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

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!