If you want to organize an agile program, so you can manage the stream of features in your agile program, you have some options. It depends on the size of your program. The communication structures in your agile program matter.
How Large Is Your Agile Program?
I think of programs as small, medium, and large. Yes, it’s a generality, and it’s been helpful to me. A small program is up to three teams. A medium program is four to nine teams. A large program is ten teams or more. Your mileage will definitely vary. It varies because of the size of the teams.
Here’s why I find the these guidelines useful. Remember back when I wrote Why Team Size Matters? If you try to graph the communication paths for a 5 -person team, you have a graph that looks like the one to the left.
Now, you’ve only added one more person, and you’ve increased the communication paths by five. This is why the size of the team matters when you think about your program and whether you have a small, medium or large program.
If you have four-person teams and you have three teams, you have a small program. If you have ten-person teams, you might still have a small program. But you’re pushing it. You might have a medium size program. You know how sometimes you have to change the data structures in code when the size of the data changes? The same thing happens with a program. You want to think about the organization and communication structures you’re using, to make sure they enhance the product development you’re doing, and not holding you back.
Remember that an agile team depends on the micro-commitments every single day between its members to make progress. The more teams you have attempting to make progress on features across the organization, the more you want to enhance that communication. So you want to select a program organization that enhances that communication.
Programs Have Communication Paths, Too
In an agile program, the technical project teams make commitment to and with each other. They have communication paths not just inside the teams but between the teams. The way they communicate can vary depending on whether the program is small, medium or large. How you organize the program will change how you communicate. You have choices.
Many people use Scrum as their agile approach of choice. Scrum is a great project management framework. It’s designed for a 5-7 person collocated team.
If you want to scale Scrum, especially for small programs, many people use a technique called Scrum-of-Scrums.
Scrum of Scrums is a Hierarchy
I have nothing against Scrum-of-Scrums. In my opinion, it’s a lot of overhead for not a lot of return, but it works for a lot of people. And, more importantly, it’s a lot more effective than what they were doing. You know me. If it’s more effective and they are successful, rock on!
And, SoS is a hierarchy. The Scrum teams get together at their standups and then send their Scrum Masters to another standup where the Masters get together and discuss the cross-program risks on a daily basis. They then have to get back together with their teams. Yes, they do this every day.
So, the problems go up the chain and down the chain. Now, in a small program, such as three teams, especially if the teams are small and the people are trained well in agile, and they are accustomed to working in small features that are written end-to-end, the people solve problems themselves. Alice doesn’t have a problem walking over to someone and saying, “Hey Bob, I have a problem. Can you take a look at this and tell me what’s wrong?”
But, what I see, even in small programs, is that the teams are not collocated. Alice is not located in the same timezone as Bob. Alice needs her Scrum Master to coordinate with Bob’s Scrum Master. And, because it’s the job of the Scrum Masters to coordinate, it’s not anyone else’s job to coordinate.
Let me repeat that. Because it’s the Scrum Master’s job to facilitate and maintain the coordination job, it’s no one else’s job to do so. Why? Because everyone else is busy getting their features to done. It’s human nature. We push problems up a hierarchy for someone else to remove if that’s how it’s supposed to be.
This is not Scrum’s fault. It is a human thing. It’s the way we are made.
Add Communities of Practice
The Scrum Masters cannot and should not track the details of everything for the testing and the architecture and the UX and the databases and and and… That will depend on your program. You may well need people on each team connected with communities of practice. And, you need someone from each team connected with the program team. So, you have more of a messy picture. But, who cares if you have a messy picture if you have a more effective program?
This picture has a community of practice built in. You can do this with S-o-S. You don’t need permission. Now, with a three-team program of small teams of only 5 people, you might not need it. But, if you have 10-person teams, or if you are geographically distributed, you might.
Ask yourself these questions: are we getting to done every iteration on every single feature on every single team? Do we have interdependency problems? And, if you are larger than three teams, you almost certainly need a different structure. If you cannot answer yes to these questions, or if you are having trouble with your features flowing through your program, you need a different structure.
Communities of practice help.
Lean Works, Too
For those of you wondering, yes, you can always move to a lean approach. This works for any size team. I’m going to talk more about this for medium and large teams, because lean really shines there. So hang in there for later.
This discussion is about communication structures between teams, not the process or lifecycle the individual teams should use in a program. As a program manager, I don’t care what the teams use as long as they meet their commitments to the program. I hope you are not surprised about that. More about that, later.
Use a Network Instead of Hierarchy
Instead of a hierarchy, you have a choice of using a network, even if you are using Scrum. Even if you just have a three-team program.
When you have a network of teams, you don’t have to have everyone interconnected with everyone else. And, you don’t just need the Scrum Masters connected to each other. You need teams tightly connected to themselves. And, you need teams with loose connections to each other. This is called a small world network.(Do not sing the Disney song. No, I told you not to!)
If you’ve heard of the Six degrees of separation from Kevin Bacon thing, this is how it works. You don’t need all of the teams connected to each other, as long as all of them are connected to some of them.
For a three-team program, all of the teams would be connected. That’s easy. Since, in agile, we want to encourage people to collaborate, the small world network pattern is a reasonable pattern to use.
With a small world network, if Bob and Alice have a question, they ask each other. It’s their obligation to do so. If they don’t know that they should ask each other, it’s their obligation to ask someone who might know. That someone is not necessarily a Scrum Master. Or an agile project manager. Or a program manager. It’s someone in their network. The question doesn’t go up the hierarchy. It goes across the network.
This is not anarchy. It’s collaboration. Here’s a quote from Clay Shirky from Here Comes Everybody: The Power of Organizing with Organizations
Collaborative production, where people have to coordinate with one another to get anything done, is considerably harder than simple sharing, but the results can be more profound. New tools allow large groups to collaborate, by taking advantage of nonfinancial motivations and by allowing for wildly differing levels of contribution.
I’ve drawn my picture using five teams, because while the small world network is useful for small programs, you can really see how it starts to shine for medium programs. For a small program, use the simplest thing that works. (Do that anyway.) The real question is this: Does what you are doing scale, as your program grows?
For my clients, the answer has been no. In fact, for my clients, Scrum of Scrums has not even worked for three teams. Why? Because they have not gotten training or coaching. They have tried to learn Scrum out of books. They have sent one person to one class and attempted to learn it that way. This is not a successful way to learn anything about agile.
When my clients drop the Scrum of Scrums approach and revert to networks, which is how their work got done in their organization before, they get their work done. Don’t ask me why they thought all the questions had to be funneled through the Scrum Master. I have no idea. I do know that the network approach works for them. And, it’s a lot less overhead for the poor Scrum Master/Agile Project Manager
Why Does a Network Approach Work?
The small network pattern works because it puts the inherent rumor mill to work for you. The small world network engages people in a way that hierarchy does not. And, it decreases the transaction cost of just about everything. That makes a huge difference. You don’t have to wait for any standups to address problems, issues, or risks. People on teams solve problems when they have the problem. No need for a “master” or a “chief” to intervene. You know how much I dislike the chief titles business.
In the next parts, I’ll talk more about how networks help, especially for medium and large programs and how they help features move through programs.
Thanks for hanging in there with me. I tried to make this short, but I am not a good enough writer to write this short. Please, ask me questions.
Reference: Organizing an Agile Program: Part 1, Introduction from our JCG partner Johanna Rothman at the Managing Product Development blog.
