Imagine you are transitioning to agile. You are a program manager, with a couple of agile projects, and a couple of traditional projects. How do you manage the program?
Technical Program with Communities of Practice
Here’s what a program team looks like. For the sake of argument, assume that Sally is an agile program manager, because we can tell she’s working by feature sets. But, maybe Henry doesn’t know anything about agile. Henry’s team is still working on a feature set. It’s just that it’s 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 Josh’s and Tim’s team. 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 non-agile 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, this is a huge change. 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 see how to see all their work in progress. This will help them all see their dependencies. (See the Silent Project Killer.) 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 traditional projects into chunks with interim deliveries. Yes, that turns those projects into staged delivery lifecycle projects. Yes, that’s cheating, they are no longer strict waterfall projects. That’s ok. No one gets credit for strict adherence to strict lifecycle. People get credit for successful projects and programs.
And, 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. You, the program manager, 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 to the project managers the results I wanted and when they needed it, coaching them directly to help them deliver what I wanted.
This is not about forcing Henry 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. See What Lifecycle? Selecting the Right Model for Your Project.
If you want to read much more about deliverable-based planning, rolling-wave planning or lifecycles and how you can use them, read Manage It! Your Guide to Modern, Pragmatic Project Management. The Prags carry it in print and e-book versions. See the sidebar for clickable links.
Do you have other suggestions?
