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

Let’s set the context (which I did not do in my most recent post–sorry).

Let’s set the context (which I did not do in my most recent post–sorry).

Technical Program with Communities of Practice

A program is composed of several feature teams, which may well be working on several projects or different feature sets. I assume they are. The goal of a program supersedes the goal of any of the projects, and the business gains much more value from the program than from any of the projects by itself.

So, the question before us is this: How do you help the teams bring the entire product together on a periodic basis, regardless of their technical practices? If you look at the comments from yesterday’s post, you can see that continuous integration is a real problem for any number of reasons.

Remember, on an agile program, the agile program manager facilitates the work of the projects/feature teams, the agile program manager does not demand. The agile program manager does not lay down the law. The agile program manager does not say, “Here’s how it’s going to be, folks.” Even I, as much as I have wanted to in the past, have not done this. Oh, you have no idea how much I have wanted to say this.

On the other hand, the agile program manager can point out the consequences or risks of not taking certain actions. “If we don’t integrate as we go, we will never meet this demo date.” Or, the trade show date, or the desired release date, or some other date. Or, manage some other risk.

I’m quite happy to explain the risks to the feature teams. They are adults. They know how to get married, raise children, dress themselves, get to work clean, fed, and live adult lives. Ok, we’re talking about technical people, so sometimes we have outliers :-). But if the technical program manager explains the risks, or even says, “I have a funny feeling about this, and I can’t explain it, but I think this is risky, and I would like your help on managing the risk of not integrating as we proceed,” most people will respond and say, “Okay, let’s see how we can get closer to continuous integration.” Or, they will say, “Hey, this is really hard,” or “This is really expensive,” or “We know how to do it with lots of branches which is crazy,” or “We only know how to do it we break the build” or any number of other problem statements.

They’re not stupid. They may be intimidated by continuous integration, but they are not stupid. And, they may have doubts about the cost of servers or breaking the builds—doubts which are real.

Ask for the Problems or Impediments First

You can’t solve the problems you don’t know about. So, ask for the impediments first. You might be surprised. Maybe you need some servers. Maybe you need a release/deployment team.

Maybe the feature teams don’t really understand the problem either. Here are some guidelines for the problems and impediments:

Ask for the result you want. If you want continuous integration, explain that’s what you want. I say something like this, “I want the system to be in a releaseable state every day. At a minimum, I would like that every week. I know that’s not where we are now, and that’s the result I would like. What would it take for us to get there?”

Assume the technical teams understand the technical problems better than you, the program manager do. If you ask for the problem and impediments, don’t poo-poo the problems. Treat the problems and impediments seriously. Assume the technical

Pages

About the author

Johanna Rothman

Johanna Rothman is a management consultant and a regular StickyMinds.com and Better Software magazine columnist. Johanna is the author of the recently published Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It! Your Guide to Modern, Pragmatic Project Management--winner of the 2008 Jolt Productivity Award, as well as the coauthor of Behind Closed Doors and author ofHiring the Best Knowledge Workers, Techies & Nerds. She is a host of the Amplifying Your Effectiveness Conference. Johanna has presented at STAREAST, STARWEST, the Better Software Conference & EXPO, and Applications of Software Measurement & Management conferences. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.