Know Your Program: Which Team Are You Managing?
Some program managers whose organizations are transitioning to agile are not always clear which program team they are managing. Sometimes, that’s because the organization doesn’t realize it needs more than one program team.
If you are coordinating and collaborating across the entire organization, you are part of the core program team. There are plenty of potential participants on this program team: the program manager, the software program manager, the potential hardware program manager, the program product owner, sales, deployment, legal, marketing, finance, HR, investor relations, and project managers. There might even be other people or different people in your organization.
For a sufficiently large program, the software program manager should be a delegate to the core program team. That means the software program manager must have a program team of his or her own.
On a technical software program team, the program product owner and the program architect work with the software program manager as a triad to make risk decisions. Does that mean the program product owner does not work with the core program manager?
Your project teams might need their own program architects on their teams. A Scrum-of-Scrums project—which, if it gets bigger, might be its own program—likely needs its own architect. That architect better talk to the program architect. And if there’s a hardware architect, that architect better talk to the program architect. So you might need a cross-functional architecture team.
So, if you are a program manager, are you on the across-the-organization, core program team? If you are not on the core team, are you on the technical team that works across the technology? Do you have everyone you need? Who has responsibility for deployment?
You may be wondering why you need all these program teams. The core team runs on a different rhythm than the technical program team does. Because the core team has senior managers or senior people on it, I recommend the core team use kanban to reduce the work in progress. The technical program teams can use iterations if that works for them. Maybe they also use kanban; it doesn’t matter. But they address risks at different levels.
The core program team is much more strategic. Often, program managers at this level manage budgets and project portfolio issues. They are the ones to say, “Wait a minute. The software program can’t succeed. We should stop this project.” That’s a project portfolio issue.
The technical program team is more strategic than a given project but is not as likely to manage budgets or project portfolio issues.
Program management, especially for many teams (think more than twenty), is about making sure you have a product that delivers the business value you want from all that effort. So the technical program will have its own risks and rhythm, which are separate from the core team’s risks and rhythm.
If you are a program manager, make sure you know which team you are managing so you can be most effective.
