Organizing Programs
I've been working with clients who have large programs, sets of projects often all over the world. Especially as these folks transition to agile, it's not easy to see how to organize the program. One of them, Sherri, asked, “Should we follow the architecture of the product, and have front-end, middleware, and back-end programs? It's tempting, because that's how we've organized in the past.”
Those of you who have seen me in person are not surprised by my reaction. Sherri laughed out loud at my face. “JR, I suspect just by looking at you, that's not such a great idea.”
I explained that she wanted to do slices of the architecture through the program, even though the program was large. “Separating the teams into front, middle, and back-end teams guarantees you will have integration problems late in the program. Oh, you might get lucky, but who wants to plan on lucky, when you can organize for feedback early?”
Organizing the technical program teams is not an easy problem. If you have hardware as part of your program, you may need both hardware and software program teams, each with their own program product owners. Those technical program teams would each have a program manager who would report to the core program team who would gather the necessary people across the organization.
Sometimes, you can manage with one level of program team; sometimes you need two levels. It depends on how many people you have and if you ever have to make decisions. If you never need to make decisions, it doesn't matter how many people you have on the program team. But, if you do need to make decisions, reduce the number of people on the program team, so you can make decisions. How many is that? It depends on your organization, and how well you make decisions.
Let me recap.
- I avoid separating the technical program teams into front-end and back-end programs. Instead, I integrate them into one software program.
- I do separate the software and hardware efforts into two separate programs if they are large enough to do so, because they often run on different rhythms and different budgets.
- I separate the corporate program issues, decisions and risks from the technical issues, decisions, and risks. I call the corporate issues, decisions, and risks the “core” program team and try to keep it to a manageable number. Sometimes that even works! Because I separate the core team from the technical teams–the software and hardware technical program teams–the software and hardware programs can make their own decisions in time.
Organizing programs is not easy and it may not be intuitive for you. Consider how you often want to be able to integrate the product, and how you want to be able to reduce risk and make decisions. That should help.
I have a full speaking calendar this fall. I'll be working with people at
AYE about program management. I'll be addressing the issues of geographically distributed teams at
AYE and
Agile Testing Days. And, I'll be working with people about those issues of authority and collaboration at
AYEand
Øredev. I do hope you join me at at least one of those venues.