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.
Yes, 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.
| Reference: | Defining “Scaling” Agile, Part 2: Program Management for Product Development from our JCG partner Johanna Rothman at the Managing Product Development blog. |
