3 Essential Practices for Scaling Agile from One Project to a Program

What does “scaling agile” mean to you? For me, there are two ways to think about scaling: one is moving from one project to a program. The other is sharing agile across the business.

Let’s talk about moving from a one-team project to agile programs. A program consists of several projects across the organization. While each project is valuable, the real value is in the total deliverable, when all the projects deliver the product.

Here are three essential practices when you move from one agile project to an agile program:

1. Let teams decide how they work as a team. You might work in an organization where someone in a PMO or in management says, “All teams should work the same way.” I can see why people might want that, but it’s not a good idea and it’s not necessary.

Each team needs the autonomy to manage its own process. The more interrupts a team needs to manage, the more they need kanban. The more a team has to use spikes to learn, the more they might need the structure of a timebox to make sure they deliver features and learning. A team might want to use both kanban to monitor their work in progress (WIP), their cycle time (average time to release a feature) and iterations to provide a cadence for retrospectives and demos. (See Timebox or Kanban—A False Dichotomy for some ways to think about flow-based and iteration-based agile.)

We do care that the teams deliver finished features on a reasonable cadence. And, it matters if the teams create a finished product also on a regular cadence.

2. Deliver working product as often as possible. I like asking teams to make sure they can demonstrate the entire product at least as often as once a month. I would love to see working product every day, but I will take an all-product demo each month. For many teams new to agile, delivering running, tested features once a month is a huge challenge.

I also like asking the entire program to release outside the organization at least as often as once a quarter. If you have a program with a hardware component, releasing might not be a good use of money. But, if you work on software-only programs, having an external release at least once a quarter shows your customers that you produce value often. That value might provide you the opportunity to change when you recognize revenue, determine capitalization or acquire new customers.

3. Use lean at the program level. I like using two cross-functional teams at the program level: the core team and the software program team. (See Agile and Lean Program Management: Scaling Collaboration Across the Organization for more explanation.)

The core team is the cross-functional business team with members from all around the organization. The core team helps coordinate the efforts that make the entire product a successful deliverable. You might need someone from finance, sales or legal because your program has small projects in those areas. Those people would be on the core team.

The software program team helps the feature teams collaborate by solving problems the feature teams can’t solve themselves. Aside from collecting the feature teams, the software program team might include the program architect and a program deployment person.

I don’t want a program architect to tell everyone what the architecture should be. Instead, I like it when the program architect can work with me as a program manager to help identify and manage risks. The program architect might say, “I’d like to lead the effort to explore in that area of the program for a little while and answer these three questions.” That effort can educate or help the program product owner.

In my experience, using iterations at the program level doesn’t work too well. The core team and software program team collaborate with each other, but they don’t work on the same problems. Their deliverables are parallel, not something they can work on and deliver together.

For that reason, I like using a kanban board for the core and software program teams. I especially like to have a “Waiting” and/or “Decision Time” columns. It’s too easy for the program teams to have work stuck; seeing that stuckness helps the people decide what to do.

See how these practices work
Let’s assume Amy is a software program manager. The software program team helps the software teams succeed, removing impediments that the software teams have in common. She works with Lew, a core team manager. The core team makes the organization-wide business decisions that help the program create the most value.

Here’s how this might work in practice: Amy and Lew face late deliverables, and a concern that the program is not proceeding on time. Lew is worried that the core team will face problems because of pricing and hardware. Amy is concerned that the software can’t release regularly.

Lew is worried about the pricing decisions, and the hardware that the program will need in a month or so. He’s ordered the hardware, but the provider is notoriously slow. In addition, the sales guy, Brian, hasn’t started the pricing decisions the program will need before it can release.

Lew created a kanban board that helps people see what’s not started (pricing) and what’s in progress (the hardware). Just seeing the work in progress helps people focus on it. And, he can ask about progress in one-on-ones and at core team meetings.

Amy has her hands full with the software program. She has 14 teams, organized as three small programs of three teams each (nine teams), and another five independent teams. That’s eight people right there on her software program team.

One of the small programs is having trouble releasing because they depend on the platform teams, one of the five independent teams. Today, Amy is going to talk to the platform project manager, Sue, and the program manager, Bill, for the program in trouble. Amy has walked around to the platform team’s area, and they have a ton of work in progress. Amy wants to help them finish their work and she’s not going to interfere until she knows what’s really going on.

Amy asked Sue and Bill to make a board with all the in-progress work, all in one place. Once they did, she asked them which features needed to get done first. Now that they had that information, they could return to their teams and ask to finish some of the work first.

One of the problems is that Sue’s product owner and Bill’s product owners were not synced about the features to finish first. Amy called the program product owner and asked what his ranking was. Armed with that information, Amy asked the product owners to meet to define smaller deliverables so they could sync up with the overall program and decrease the work in progress.

Program managers manage the “scaling”
These three reasonable practices:

  1. Team autonomy
  2. Regular delivery
  3. Use lean to see work in progress

…are just that: reasonable. You might need other reasonable practices to help your program deliver.

Whatever you do, don’t think you can scale what one team does to every other team. That will provide you bloat, not delivery. Each team needs the ability to manage its own work in its own way. When teams deliver, the entire program wins.

As a program manager, you have several roles: facilitate problem-solving across the organization; investigate what’s really happening so you can help people make good decisions; and to see what is done and what’s not done. When you can see what’s done and what’s not, you can help solve the problems across the organization.

Programs are about delivering a product that is greater than what one team can do on its own. When teams exercise their own autonomy, they can decide how to deliver working product all the time. Add in the ability to solve problems the teams can’t solve on their own, and you have an agile program.

Leave a Reply

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