Imagine you are transitioning to agile. You are a program manager with a couple of agile projects and a couple of traditional projects. Sally is an agile program manager working by feature sets. Henry’s team is still working on a feature set, but Henry doesn’t know anything about agile, so the team is working on a feature set as if it's a waterfall team.
If you are the software program manager, how do you manage the program? If you work in iterations, what happens at the end of every two weeks? Henry has nothing useful to say and is bored. He can’t tell you anything about risks. He wants specs. Sally’s program wants to know when Henry’s team is going to be ready to integrate, and of course there is risk with the other feature teams. You know that if this continues, you will be in trouble. What do you do?
- Use deliverable-based planning for all projects. It doesn’t matter if a project is agile or not. Every project must have deliverables. It happens that the agile projects will deliver those as features at the end of iterations. The nonagile projects have to deliver the deliverables at interim milestones.
- All projects use an incremental approach to delivery. No one can wait until the end of the program to deliver. For some project managers—and for some testers—this is a huge change.
- Use rolling wave planning to plan the program. You don’t have to keep a four-week wave—you can use a shorter wave. I would not use a longer wave than four weeks.
- Measure the cumulative flow for each project, or show the project managers how. They each need to know how to see all their work in progress. This will help them all see their dependencies. The more interdependencies they have, the more they have to talk with each other to break them. They might need more deliverables. They might need a kanban board to see bottlenecks. But until they see work in progress, they won’t know what they need.
When you have programs with traditional projects, you have to help the traditional project managers break the projects into chunks with interim deliveries. Yes, that turns those projects into staged delivery lifecycle projects. Yes, that’s cheating because they are no longer strict waterfall projects. That’s OK. No one gets credit for strict adherence to lifecycle. People get credit for successful projects and programs.
The issue with program managers and transitioning to agile is that you might have to coach the project managers into working in new and different ways. As the program manager, you have to understand all about project management. I suppose you could get a coach in to help the project managers. I have been more effective explaining directly to the project managers the results I wanted and when they needed to deliver them.
This is not about forcing the Henry in your program to transition to agile. This is moving Henry gently from strict waterfall to waterfall with deliverable-based planning and interim deliveries, which smells a lot like staged delivery.
Do you have any more suggestions for managing a program that's transitioning to agile?
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. She is working on a book about agile program management. She writes columns for Stickyminds.com and Gantthead.com, and writes two blogs on her web site, jrothman.com, as well as a blog on createadaptablelife.com.