Managing Programs With Agile and Traditional Projects

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
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?

  1.  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.
  2. 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.
  3. 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.
  4. 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?

6 Replies to “Managing Programs With Agile and Traditional Projects”

  1. Hi this is a great post, however I don’t see where you discuss how you go about creating a product backlog with a program with both agile roots and legacy waterfall projects? I’m doing just that but have no consistent backlog in my program yet. Is that a requirement? Seems to me that it is but how to with waterfall projects still coming in?

  2. A follow up to Mark Gustafson inquiry. Maybe I missed the post Johanna, but I to am interested in a traditional program plan with product backlog components as well. You bring up a good point with respect modeling it after use cases. Have you any more information on this (reference URLs will work)

    1. Hi Anx, you do need a backlog. I guess I assumed that the agile projects would have backlogs and the non-agile projects would have SRS’s. Do they?

      If possible, you want to convert everything to backlogs, so you can get everyone to think about, “What is my first deliverable, and how early can it be?” That’s the way to think about deliverable-based planning. Do you have “Manage It!”?

  3. Hi Johanna – most of our projects have Software Requirements Specification (SRS) as well as Functional Requirements Specifications (FRS). I guess where it is not clear is 1) how would one mold the structure of agile project with backlogs into a traditional program plan and B) how does one distinguish between SRS and FRS in the traditional project management plan.

    No I do not have “Manage It!”. Is it possible to get a complementary copy or a pdf?

    1. Anx, so you folks are not agile at all. You can read some excerpts of Manage It! at and buy a copy there. Have you had any agile training?

      Do not start agile on a program. A program is too large.

      If you are wedded to your plans and documents, and have no agile training, please do some reading, get some training, and then we can talk. (We can talk by email too. Let’s not talk on the blog.)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.