Understand Your Teams' Concerns about Moving to Continuous Integration
A program is composed of several feature teams, which may well be working on several projects or different feature sets. 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 project by itself.
The question is: How do you help the teams bring the entire product together on a periodic basis, regardless of their technical practices? Continuous integration is a real problem for any number of reasons.
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 and 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 would say something like, “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, does. If you ask for the problem and impediments, don’t dismiss them. Treat the problems and impediments seriously. Assume the technical people are correct about the issues.
- 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.
- Involve the communities of practice in generating the solutions to these problems. That’s what they are there for. Use them.
- 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.
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.