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

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:

1. 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?”
2. 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 people are correct about the problems.
3. Use the rule of three for each potential solution. That is, for each problem, develop three potential reasonable solutions to that problem. That way, everyone understands the problem well enough. If you only have one potential solution, chances are quite good no one understands the problem well enough to solve it.
4. Involve the communities of practice in generating the solutions to these problems. That’s what they are there for. Use them.
5. Ask for project or feature team volunteers to try a solution before committing the program to it. Never impose a solution on the entire program. If no one is willing to volunteer to try a solution, it’s not reasonable. Go back to the drawing board.

Some of the teams will need different initial solutions. Some teams will need help making their stories smaller. Some teams will need help learning to swarm around their features, so they finish features earlier in the iteration. That sets each team up for success for continuous integration. Remember my story back when I was at university? We might have succeeded on that small project if we had worked together on the features, instead of working by ourselves.

But those impediments might be just the tip of the iceberg for your teams. Once you start generating some options, you can start to see what the costs are, and you can start comparing the value.

I will have some options in my next post.