and inside of no more than two weeks, each team has experienced continuous integration. Now, when the technical program team meets, they can intelligently discuss what they need for program-wide continuous integration. They will learn about collisions, where they need scripts, tests, tools.
What About the Waterfall Teams?
Some of you have waterfall teams in your programs, too. They need to use deliverable-based planning, rolling wave planning to get to the deliverables, and deliver something every quarter. This is called a staged delivery lifecycle. Or a design to schedule lifecycle. It’s an incremental lifecycle. Read more about these lifecycles in Manage It! .
Get Help if You Need It
Do you need a release or deployment engineer or team to help you with integration? I hope not. But as you start your program, if you are not accustomed to continuous integration, you might. As a program manager, I might have a release/deployment team to start to manage the risks, and see if I could help those people into feature teams and out of a release/deployment job.
Only you, the program manager, your product owner, and your program architect as the triad to assess the technical debt and business value of the backlog and technical risk can know the value of continuous integration on your program. Maybe you have well-behaved code, and the cost of continuous integration is not worth the aggravation.
But, if you are like the programs I see, the value of continuous integration is quite high. Consider the options for your program. The more teams you have, in general, the more value you will get from continuous integration. You will be able to see the state of the program more often, because the program will be demoable and releaseable more often.
My guidelines are these: small programs of up to three teams: let the teams decide. Programs of 4-8 teams: nudge the teams into continuous integration, using cumulative flow and show them the value of not having lots of work in progress. Programs of more than 8 teams: continuous integration is not negotiable. You either pay for it now, or you pay a lot more and have a disaster later.
If you see more options than I’ve outline here, please do comment.
Pages
About the author
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.
