I keep hearing a lot about “chief” this and “chief” that when it comes to Big Agile, aka program management. You know, chief product owner, chief architect, that kind of thing. I’m kind of puzzled. I thought agile was all about self organization and no command-and-control. Chief anything reeks of command-and-control to me.
At the same time, I understand the need for coordination among many teams to produce a usable product. Let’s discuss what the need might be, and how you might get there.
How large is your program?
First, what’s many teams? Programs come in small, medium, and large sizes. A small program is three teams or fewer. A medium program is four to nine teams. A large program is ten teams or more. Why do I draw the lines with these numbers? Because of the program teams.
Core Program Team
Technical Program Team
The core program team (the program team at the executive level) has to be able to communicate. And so does the technical or software program team.
The larger and more complex the program, the harder it is to communicate. Remember my post about Why Team Size Matters? It matters for project teams, and it matters for program teams.
The more teams you have at the technical team level, where you see Joe, Tim, Henry, and Sally, that level, the harder it is to communicate. And you can see that Sally is managing another six teams. Sally is managing a small program of her own.
The name “chief” implies a hierarchy. But the large your program, the less you want a hierarchy. Why? Hierarchies are difficult to navigate, especially when you need to solve a problem. The problem has to go up one side of the hierarchy and back down another to get solved. And, who knows if you’ve even found the correct hierarchy to solve the problem?
That’s why I’ve drawn these pictures more like wheels of networks.
The idea is that each program team, the core program team and the technical program team is a network of people, responsible for solving its problems. And, the technical project teams which report status to the technical program team are a network of people, too.
The program manager is responsible for the business value of the program overall, shepherding the program, managing risks, and helping to release the program when it has value to the organization. The program product owner is responsible for the business value of the roadmap. The program architect is responsible for the business value of the architecture. Note that I did not say how these people are supposed to carry out these responsibilities. As with all programs, your mileage will vary. I will provide examples as I write more in the book.
Think of networks, not hierarchies
But if you think of networks, and not hierarchies, you are much more likely to get the business value from your program. In my never humble opinion, calling the program product owner a “chief”, and the program architect a “chief” reinforces the idea of a hierarchy.
Now, you might need a person to be the chief architect, one person to make all the final decisions. That’s okay. Say so. You might even need one person to be the chief product owner, to be the person to make the final decision about the roadmap and the backlog. Say so. But make it a transparent decision.
If you’re transparent about it, I’m happy with your decision. I only have a problem with people who say, “Anyone can change anything,” but not everyone can. It’s shades of Animal Farm, where some people are more equal than others. Let’s be honest. We can do anything as long as we are honest about it. Well, almost anything.
I thank Esther Derby for articulating this notion of networks in her Agile 2012 talk, Scaling Agile Teams: Principles and Practices. The video is not up on the Agile Alliance site or I would point you there.
