Imagine you are transitioning to agile. You are a program manager with a few agile projects and a traditional project. How do you manage the program?
Possible Technical Program with Communities of Practice
Above is my drawing of what a technical program team looks like. Sally’s project is actually a small program itself. Sally is not the program manager in the middle. She is project manager, managing a subproject that happens to be quite large. She has six small teams, all working on one large feature set. For example, they could be working on the platform for a large program. All the “S” people working with her are Scrum Masters, working on their feature sets. They are coordinating the work of their Scrum teams to deliver the work of Sally’s project into the entire program. Joe, Tim and Henry’s teams all need to coordinate with Sally’s teams.
Let’s assume Joe and Tim are working in an agile way. They are all working on the same product. But maybe Henry doesn’t know anything about agile. Henry’s team is still working on a feature set. It’s just that Henry’s team is working in a waterfall way.
If you are the technical 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 Joe’s and Tim’s team. You know that if this continues, you will be in trouble. What do you do?
Start with Deliverable-Based Planning
I would start with deliverable-based planning for all of the projects in the program. It doesn’t matter if a project is agile or not–every project has deliverables. It happens that the agile projects will deliver those as features during and at the end of iterations. The non-agile projects have to deliver the deliverables at interim milestones.
Because every project has deliverables, you can also use not-at-the-end integration. And, if you also deliver those deliverables every few weeks, you know that you can build in checkpoints often so you can see progress in your program. That’s one way of managing program risk. Now, deliverable-based planning is not going to make Henry’s project agile. However, it will make it more adaptable–and less prone to being the place where all the risk comes home. And that will be helpful.
Continue with Increments of Delivery
Deliverables and not-at-the-end integration means you can see increments of delivery. This means that all projects in the program 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.
For people accustomed to a traditional way of working, delivering some piece of functionality early–especially if they know lots of the rest of their piece of the system doesn’t work–is frustrating. Developers don’t want to release something half-baked. Testers don’t want to have to go back and test something, especially if they are manual testers. The testers might not even know how to test. The developers might have to build special test harnesses for them.
Project managers don’t know how to help the team estimate the remaining work. Be prepared for people to say to you, “It’s a mess. We can’t work this way.” Instead, you can help that team look at an early release as a way to obtain feedback. Encourage the testers to automate tests underneath the GUI; they will want to run these tests again as the developers add more features. Those additional features will require regression testing of earlier features.
When a team releases early, the integration and testing is about obtaining information. Help the team realize that, and they will no longer be as concerned about early releases.
Use Rolling Wave Planning to Plan the Program
Use rolling wave planning to plan the program. You don’t have to keep a four-week wave–you can use a shorter wave (but I would not use a longer wave than four weeks). If you’re not sure what rolling wave planning is, here’s a short introduction: With the project managers, plan the schedule for the program for the next X weeks, where X is your wave. They have an idea of their deliverables. They may not have a perfect idea, but they have an idea. You might need the product owners in the room with you. As one week completes, the project managers add another week to the end of the plan. They refine the weeks that are there. You never have a schedule longer than the rolling wave, but your rolling wave looks pretty good.
If you have a small-enough program (such as three project teams), you could do this with all the teams in one room. But once you have more than three teams, you might have too many people to do this. You need the project managers to be surrogates for their teams. You ask the traditional project managers (such as Henry) to schedule their projects like this the entire time. They have the flexibility to modify their schedules to adjust to the changes in the backlogs as the agile projects change. It also helps them to keep their features smaller.
Not all project managers are happy to do week-at-a-time scheduling. Explain that the risk of longer than week-at-a-time scheduling is too high. You, as a program manager, don’t need to know their details. You need to know that they know their details. One of the valuable results of rolling wave scheduling is that they might discover interdependencies and risks as they create their waves. This is a great thing.
Measure to See the Work in Progress
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 agile projects and 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 okay. No one gets credit for strict adherence to a specific lifecycle; people get credit for successful projects and programs.
Agile Program Manager Becomes a Coach of Project Managers
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.
Agile program management is not about forcing Henry or anyone else 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. It’s about being effective as a program manager. It’s about delivering a product your customers want.
Who cares how you do it?
This article was originally published on projectmanagement.com