Design Each Team’s Project to Optimize at the Program Level
If you are part of a program, it’s not enough to design your project for your team. You have to consider the needs of the program, too.
Each team needs to ask itself, “How do we deliver what the rest of the program needs, as the program needs it?”
You might want to watch Philip Evans's TED talk, "How Data Will Transform Business." In a hierarchy, we have too-high transaction costs. Hierarchies are slow to respond. They impose barriers where you don’t need any.
The problem with programs is that they are big. You want to decrease the problems of bigness where you can. One way to do that is to decrease the effects of hierarchy by not involving hierarchy whenever you can. That means using small world networks to solve problems between and among teams. That way you solve problems only where the problems exist.
If I ran all the programs in the world, what would I do?
- Have feature teams everywhere, not geographically dispersed project teams. I prefer collocated teams, but I realize in very large programs that is not always possible.
- Have a core program team (cross-functional business team) that runs itself using kanban. If you need a cadence, use a one- or two-week iteration for the team’s problem solving.
- Have the technical program team run itself using kanban. Use the same problem-solving cadence idea.
- Have the project teams use their own approaches to agile and lean, recognizing that their job is to reduce batch size, get to releaseable all the time, and not incur any technical debt as they proceed. The more the project teams are autonomous in their approaches to agile, the more they will collaborate with each other.
- Have the program architect (who represents the business value to the core team) look for examples of bad implementations of Conway’s law all the time in the product. That will help create architectural business value.
- Encourage Communities of Practice (CoP) for the functional areas. Encourage cross-pollination between the communities. The “plain” developers need to know what the architects are thinking, as do the testers. The developers need to know what problems the testers are solving, and so on. Organizing and facilitating CoP is a management job and a servant leadership role. It’s definitely not a command-and-control role. The word here is encourage, not mandate.
- As a program manager, you need to be aware when people need more training in understanding deliverables or what those deliverables are. Do they understand flow? Do they understand agile? Do they understand feedback? Do the teams need coaches? Do the teams need help—in project management? in the interpersonal skills? in the engineering practices that will help them deliver a clean feature every day or so into the code base?
Keep these three words in your pocket for your teams: autonomy, collaboration, and exploration. The teams need to be autonomous. It’s their deliverables that you care about, not the teams being in lock step.
