Some program managers whose organizations are transitioning to agile are not always clear on which program team they are managing. Sometimes, that’s because the organization doesn’t always realize they need more than one program team.
Core Program Team
If you are coordinating and collaborating across the entire organization, you are part of the core program team. If you take a look at the Core Program Team image on the left, you can see that there are plenty of potential participants on this program team. Aside from the program manager, there is the software program manager, the potential hardware program manager, the Program Product Owner, the Sales, Deployment, Legal, Marketing, Finance, HR, Investor Relations project managers. And those are only the people I could imagine. There might be other or different people in your organization.
Notice that the Software program manager is a delegate to the core program team. That means that the Software program manager must have a program team of his/her own. Yes. That is true for a sufficiently large program.
Below is what that technical Software program team looks like. Notice that the Program Product Owner and the Program Architect work as a triad with the Software Program Manager to make risk decisions. Does that mean that the Program Product Owner does not work with the Core Program Manager?
Software Program Team
It depends. It depends on who needs the Program Product owner. Maybe you need a product owner team, and the program product owner works with the core team and the technical product owner works with the software program owner. It depends on what your program needs.
Look at the Program Architect. Your project teams might need their own architects on their teams. Sally’s project–which might be a Scrum-of-Scrums, and 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 that I don’t have a picture of, right now.
So, if you are a program manager, first, are you on the across-the-organization program team, the core team? If so, do you have everyone you need? Does that team have responsibility for deployment? (I don’t care who has responsibility for deployment, as long as someone does.)
If you are not on the core team, are you on the technical team that works across the technology? Does this team have responsibility for deployment? I’m being a little touchy about deployment because I have consulted to programs where no one was responsible for deployment and they only discovered it when I asked, “Who’s responsible for deployment?” I thought I was being stupid because I didn’t see it. No, no one had thought about it. Oops.
So why do you need all these program teams? The core team runs on a different rhythm than the technical program team does. Since the core team has senior managers or senior people on it, I recommend the core team use kanban to reduce the WIP (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 budget or a project portfolio issue.
Program management, especially for many teams (think > 20 teams) 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 is separate from the core team’s risks and rhythm.
If you are a program manager, make sure you know which team you are trying to manage (coordinate and collaborate), so you can be most effective.
