Defining “Scaling” Agile, Part 2: Program Management for Product Development

The first post was about scaling functions to working as collaborative agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program.

The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a program, a collection of several projects with one business objective.

Programs come in a wide variety of shapes and sizes. Here are some kinds of programs:

  • You might have just one feature team and need people from Marketing or Legal to release the product. You need to bring those people into the program somehow, so they can accomplish their deliverables so the organization can release the product.
  • The project is larger than one or two feature teams. You may have several feature sets and need people from Marketing, or Legal, or Finance (or someone else) to be able to release the product.
  • You might be managing the software program, and have several feature teams or programs within the larger program. You might have the Engine program, and the Admin and Diagnostics programs. Each feature set has several teams collaborating on the code in their feature set(s). And, you probably need people across the organization to finish the work for the product. Those are the people from Marketing, Legal, Finance or others that I keep talking about.

Programs exist when you need a little structure to organize the feature teams and/or organize the deliverables across the organization. Agile programs especially don’t need too much structure. The key is to create something that helps the people collaborate and visualize the work they need to complete.

Here’s a way to think about scaling to a program:

Scale the collaboration across product development to release products. 

Agile and Lean Program Management: Scaling Collaboration Across the OrganizationYes, I wrote a book about that:  Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Here’s how I think about scaling collaboration across product development:

  • Each team thinks about how fast they can release their work to the rest of the program. (BTW, fast isn’t useful unless the work is great.)
  • Each team manages its WIP (Work in Progress) so they aren’t bottlenecking themselves or anyone else.
  • The POs work as a team so the feature teams always work on the most valuable work for the program. Sometimes, feature teams move from one feature set to another because that work is more valuable. If you’re worried about interdependencies, you might not have feature teams. Or, the POs aren’t working together. See Understand Your Project Interdependencies.
  • Teams use the power of their small-world networks (and possibly Communities of Practice) to solve problems at the team level. Teams often don’t need help from anyone with “manager” or “master” in their titles.

Aside from trusting the teams to deliver and asking them to let you know if they can’t, I also suggest these ideas:

  • Scale the visualization of the work. How do people see what other teams or people are doing?  (I have plenty of images of kanban boards so you can see if any of those work for you.)
  • Keep the hierarchy as flat as possible so problems don’t have to go up a hierarchy, over and down, and then follow their path back before someone gets the answer they need.
  • Consider a cadence of meetings that solve problems. These meetings are not standups. Standups might expose problems but they don’t solve them.

I recommend teams decide if they need to organize as small programs (such as above with the Engine, Admin, and Diagnostics programs). That allows a cadence of limited-participation program team meetings to solve problems the teams can’t solve.

In addition, measure at the program level. Sure, the teams need to measure their cycle time and velocity, whatever they choose. In addition, measure the features complete at the program level, program level WIP, and any other program measures that make sense to you. (See Velocity is Not Acceleration for two of these charts.)

Agile program management helps product development use agile approaches to release products. Next up is how to scale agile from product development to other parts of the organization.

2 Replies to “Defining “Scaling” Agile, Part 2: Program Management for Product Development”

  1. At the Program level, we define the needs of the constituents through a Capabilities Maturity Flow model https://goo.gl/mqtpgt
    That way everyone sees through the “big visible” chart when their needed capabilities will be available – the Estimated Completion Date (ECD) and can confirm (or change) that the business Value will be delivered as planned.

    1. Glen, I have noticed two distinct patterns in my agile clients. One uses agile because they expect to change features. The other uses agile because they are pretty sure they know what they want and the risks are primarily (but not always) in getting the work done.

      The first kind of client understands build-measure-learn loops, and creates more of those in the earlier part of the program. (If they are lucky.) The other kind of client wants to see the product and the roadmaps evolve as the teams deliver finished value.

      That second kind of client uses a chart similar to yours, once they have learned the big things. Sure, small things will still come along and surprise them, but not as many as they had originally.

Leave a Reply