When it comes to working in a team, there tends to be a trend in communicating: People talk to each other when they need to.
One of the challenges about working in a program is how to manage the check-ins, especially with continuous integration. Imagine all the features in a product multiplied by all the project teams, and you can see how you could have a problem in your program.
If project teams limit their work in progress and swarm around features, integrating as they proceed, they have fewer features in progress. And if they are in networks, they have communities of practice and ways of talking among themselves, so they don’t have to wait to sync with each other.
When features are small and they integrate every day or every other day, people expect to discuss integration issues all the time. On a large program, you might need an integration team to help keep things moving—in addition to everyone's syncing with the mainline every day by taking down the new additions to the main and syncing just before putting new changes up.
If you keep a stream of features moving in a program—even with many feature teams—you are OK as long as the project teams keep talking to one another.
You are not OK, however, if someone decides, “I own this code and no one else can touch it.”
Now, you might decide that all middleware code or all particular component code has to be reviewed. Or it all has to be smoke tested. Or it all has some other gate that it has to go through before it can be changed. Or you pair on everything. Or you have situational code ownership. That’s perfectly fine. You decide on the technical mores for your program. It’s a good idea to have them.
But the larger the program, the less you can have one gatekeeper. That person cannot be in one place, holding their fingers in the dike. This is why rather than czar-like architects who rule from afar, embedded architects who are part of the team tend to work better, in my opinion, in agile programs.
When the product reaches a certain level of maturity, you can work on a particular component as a feature and swap it in or out once you change it as a feature. This takes significant skill.
If you want to be agile for a program, you need to be leaner. You need to have smaller stories. You need to work by feature, not by architecture. You need to swarm. (Well, that is, only if you don’t want program bloat.)
