Managing Product Development

In Organizing an Agile Program, Part 1, Introduction, I suggested you think about the communication paths of your programs. Instead of hierarchies, I suggested you think of networks of teams. In Organizing an Agile Program Part 2, Networks for Managing Agile Programs, I showed you how loosely connected networks might work. I explained how you need communities of practice. I brought in the idea of roadmaps, architecture, managing the backlog and status. Now, it’s time to discuss what happens with program management on large programs, programs of nine teams or more.

How Do You Manage a Large Agile Program?

In the same way that good project management was never about command-and-control, good program management is not command-and-control. Program management is about coordinating several subprojects or a series of projects to meet some specific business objectives.

What’s the operative word? Coordination. Program managers are not order-takers. Oh, no, no, no. They are not victims, or wimps. They are the face of the program to the rest of the organization. One of my clients long ago said that they are the “grease and glue”—they grease the way for the program to succeed, and they glue the projects together. They help the projects expose the risks. They facilitate the projects. They are servant leaders.

And, if you have recently  transitioned to agile or are transitioning to agile, you are going to have confusion. The larger the program, the more confusion you will have. This is why you need small world networks. You want people to talk more to each other, and not wait for a standup. You want to use the power of the rumor mill to keep momentum going.

Inertia Is Bad, Momentum is Good

In a large program, you know how hard it is to get things moving. Not everyone has access to the same tools, you can’t find a time to meet, what works in this location doesn’t work there. Even if that location is just on another floor or across town, not across the world. Inertia is not your friend.

To prevent inertia, or if you have just transitioned to agile, here is my little trick to gain a little momentum and help people discover the value of the small world network. This also works if you have too many people on your program and you need something for them to do.

Ask everyone to start one iteration with one objective: to learn how to work together. You want to learn what done means for the program, how to ask questions of each other, if the iteration duration is the right length, whatever else you need. At the end of this iteration with any luck, you will have some features complete, an updated picture of the architecture, and you have have some questions answered. You will have started to build a little momentum, or you will know why. You will have bought yourself some knowledge. And, if you have an already-existing product, maybe you will have paid off a little technical debt. But, you will have learned.

If you don’t have anything done, you will have learned why. You and the entire program can spend the next iteration fixing those impediments. Now, isn’t that a better use of your time than a Sprint Zero where you don’t deliver features?

I am opposed to a formal Sprint Zero in a program. Why? It increases inertia and decreases momentum. Do you need to write stories? Fine, allocate time in the first two-week iteration and write stories. How much time do you need to write stories? Timebox that your story-writing to no more than four hours. Why four? Because any more time and you have Parkinson’s Law.

How long should your iterations be? Not longer than two weeks. Why? Because you have all these teams, and your run rate is high. But you say you need more time. WHY? Because you need to determine the architecture. Why? (I could go on with the five whys but I’ll stop here.) You cannot possibly determine the architecture in advance on a large program and be correct. No, you need to implement features, get some feedback and learn.

The larger your program and product, the more you need to be agile and lean. You need feedback and you need it fast.

The larger your product, the less work in progress you must have. Otherwise, your cumulative flow is off the charts and you have no idea if you can ever release. There is no reason your program cannot release every two weeks. No reason at all, unless you create technical debt.

I say, you must release every two weeks, to create momentum, to obtain feedback, and to make sure your program is not going off the rails. It’s the only way you, as a program manager can verify your program has momentum and not inertia. It’s a terrific risk management tool.

Now, you get to choose if you release to your users or just release into the code base. Release to the users is always a business decision. But release-able code? You want that in your program. Yes, you do. And the bigger your program is, the more you want it.

Sidebar: A Story From My Past

In 1988, I ran my first large software program. I had run projects and beta programs before, but this was the software effort for Symbolics’ MacIvory, the first lisp-on-a-chip. I was so excited. I’d never managed anything like this before. We had over 100 people working on the software, integrating the software with digital hardware, analog hardware, mechanical parts, and there was documentation, also. We were not Software as a Service.

We didn’t know about agile back then. But, we used Lisp, and were able to continuously integrate, or pretty much continuously integrate across the platform by feature.

Since the program was so long ago and I no longer have my notebooks, I have to reconstruct much of it from my most-likely faulty memory. I believe I asked everyone to deliver a significant milestone/demo every month. The first few months, there wasn’t much to see. You had to know what you were looking at. I used rolling wave planning to manage the schedule: What did we think we could deliver in the next month? Then, we did we do? Let’s replan based on reality.

Every day, we came in, loaded patches—yes, I ran the current experimental OS on my machine—and tried what would work on the new chip. We used the one-month timeboxes to keep our deliverables in sync with each other. We used a staged-delivery lifecycle (it’s incremental, not agile), so we could work in features and test as we went. In staged delivery, we worked by risk, not by business value.

Did we deliver everything in the nine months from the time we conceived of the idea until the demo at conference? Not everything. Did we have problems? Of course. It was a program! But, because I didn’t try to control anything, and I tried to facilitate the program and the people, it was a success.

No, MacIvory didn’t save the company. That’s because we didn’t deliver what the market needed. It was a great product, but it was not a software-only product And, we did not have a ranked backlog by business value. We worked by risk, remember? And, we never did get the marketing right. I already said it wasn’t agile.

But, that program was successful in the sense that we had a product that we could show at the trade show nine months after the program started. I didn’t generate one Gantt chart that predicted anything. We used data, the data of what we had delivered to predict the future.

We delivered feature, after feature, after feature. More importantly, the feature teams didn’t coordinate themselves through me. They coordinated themselves. They cooperated, solving problems as the problems arose. They elevated the problems and risks to me that they could not solve. They acted as small world networks. I solved problems at the program level and facilitated solutions they could not fix themselves.

Technical Program with Communities of Practice

I conducted a program team meeting once a week where I invited the project team managers, the people named in this picture. We didn’t have a single architect, so that person wasn’t invited. We didn’t have a product owner, so that person wasn’t invited. We did have a Marketing person, and a Sales person, and a Release person, and several project “managers.” I put them in quotes, because our project managers never used Gantt charts and were fairly technical. Or, they were like me, and used deliverable-based planning and rolling wave planning to ask, “How will we see the next deliverable in about a month?”

We solved problems at the program team meetings. We tracked action items. We monitored our work in progress, although none of us knew that’s what it was called. All I knew is that we had to keep finishing features and see the product evolve. No, we didn’t show demos to product owners. I said this wasn’t agile.

We could see the product evolve every day on our machines. That’s how we knew we were making progress. And, when people had questions or a problem, there was an entire community available to help.

I used that approach in a distributed voicemail system a few years later. I was unable to convince all the teams to use continuous integration. The teams that did use continuous integration had a working system from Day One. The teams that didn’t? Well, they had a difficult time, and when they started integrating finally realized what they had given up.

Fast Forward to the Almost-Present

When I started helping some of my clients with their large programs of greater than nine teams several years ago, I kept remembering MacIvory and how it worked. I remembered what we did wrong: not having a Product Owner to check that we were working on the most valuable work. I remembered what we did right: being able to see the system evolve from the beginning. How could I use the MacIvory experience to help my clients? What they were doing wasn’t working for their large programs.

One client had 17 teams. They were having trouble finding time for their Scrum-of-Scrums, never mind their demos or their retrospectives. They were not solving problems fast enough. And, they needed to put more people on the program because they were not moving fast enough. Remember, 17 teams of 5-6 people is only about 100 people. That’s not a large program as large goes. Their management wanted to put another 50-60 people on the program to increase the speed. They had more features that they could develop in parallel, so this was a reasonable approach. What were they going to do?

I met with the Scrum Masters separately and asked, “Are the Scrum-of-Scrums working for you?” Each person said, “No, they are not.” Then they explained how they were not working. Some of the Scrum Masters were not working as Scrum Masters, but as command-and-control project managers, which was a problem.  Some of the Scrum Masters didn’t know what to do, which was a different problem. Some of the Scrum Masters were successful and their teams were delivering on time. (I bet you’ve seen this, too.) In a program, you get to see all kinds of patterns and anti-patterns.

Ask for Results

The first thing we did was ask for the results we wanted. Remember, agile is also a cultural transition, and Scrum demands an entire upheaval in culture. If you ask for the results you want, you might get them, and then you can use the agile principles to generate the behaviors.

If you think about servant leadership, it paves the way for these conversations. With servant leadership, you don’t tell people how to do their jobs in detail. You tell people the results you want. You create an environment in which they can perform well. You provide feedback and offer coaching with support.

In this program, I worked with the program manager who then worked with the project managers/Scrum Masters. Some of them were Scrum Masters and some were project managers. Does it matter what they were? No, because all of them worked in two-week iterations and delivered what they agreed to at the end of those timeboxes.

And, that is the point of program management. You don’t care how people work in their iterations, or even if they do work in iterations. All you care about is when people commit to deliver certain deliverables and if they deliver them. And, yes, I worked with the command-and-control people to help them turn into facilitators.

For Larger Programs, Deliverables Matter

The larger your  program, the more you need to see demos and working product. That means you need momentum. How do you see momentum? By having people work together, integrating something every day.

Can you predict any of this? No. But if you have a product roadmap, you have a direction that people can see. If you have an architecture that they can keep in mind, they can work towards and refine it.

Remember, if you keep delivering, you can change your mind. The Product Owner can say, “Oh, now that I see this feature, I can re-rank that feature. We don’t need all of this now. We can go there, now.” This is a huge thing on programs. You can buy yourself a ton of market time if you implement across a set of features instead of deep, if that’s what the market wants.

Your project teams need to deliver fast so you gain feedback. That’s what matters, especially in a large program, because your run rate is so high. A large program is expensive. That’s why your organizations want to know how much this program will cost.

How Do You Organize Program Team Meetings?

When I worked with this large program, they decided to develop a roadmap for the program, so everyone could visualize where they wanted to go. That helped a lot. Next, they had once-weekly program team meetings of all the Scrum Masters. Yes, that was 17 people and that was craziness. That’s when the Scrum Masters decided they were at different levels.

The program manager said, “You folks decide. Should you be at this meeting? If not, decide how you will get the information. I will leave it up to you. I work for you.” She sat back down and let them work for 30 minutes.

Software Program Team

As in this picture, some of the teams were like Sally, projects that were really small programs of their own. Those Scrum Masters did not need to be at the big Program Team meeting. They needed to coordinate among themselves, but not at the big meeting.

At the end of the 30-minute timebox,  the big program team meeting had seven members, a workable number. Three of those people had small programs as Sally does in this image of a program here. They each had three or four teams for their programs, instead of Sally’s six. They had the responsibility to manage their programs as they wished.

This is all facilitating an environment for problem solving. There is no prediction. No forcing. It’s all about risk management, helping people to be more agile and lean.

Enough for today. See, this is why I’m writing a book about this. I’ll talk more in Part 4 about how to organize the backlogs. No, I’m not done with this series yet!

I have a new article up on projectmanagement.com, Managing Programs with Agile and Traditional Projects. You know the problem with a program: you have some agile projects and some not-agile projects, and maybe some projects who suffer from an identity crisis. They might think they are one or the other. You might not agree with their categorization!

Here’s the key: ask for deliverables. You might need to coach the project managers or use your influence. Now, go read the article. Please comment over there. Enjoy!

If you want to know more about how to be an influential agile leader, join Gil and me April 8-9 in Boston. We have created an in-depth, transformative experience for you. If you want to learn how to take your agile leadership to the next level, this event is for you.

Early bird registration ends today, so don’t delay. Register now. Email me with questions.

In Organizing an Agile Program: Part 1, Introduction, I discussed the difference between hierarchies and networks. I used Scrum of Scrums as an example. It could be any organizing hierarchy. Remember, I like Scrum as a way to organize a project team’s work. I also like lean. I like XP. I like unbranded agile. I like anything that helps a team deliver features quickly and get feedback. I’m not religious about what any project team in the program uses.

What works for small programs is going to be different from what works for medium programs. It is going to be different from what works for large programs. Why? It’s the scaling problem and the communication path problem. Larger programs are not linear scales of smaller programs. That’s why I asked you how large your program was at the beginning.

Using a Network in a Medium Size Program

When you look at the small world network image here, you can see how the teams are connected. This might even be ideal for a five-team program. But what happens with a nine-team program? According to me, that’s still a medium size program. And I claim that not all the teams have to be fully connected. In fact, I claim that they can’t be. No one can have that develop and maintain that many “intimate” connections with other people at work.

Note: I realize Dunbar’s Number is about 150, maybe more, maybe less. Dunbar’s Number is the number of people you can maintain social relationships with. On a medium-size program, you have a shot of maintaining relationships with many of the people on the program. Maybe not all of them, but many of them. That helps you accomplish the work.

If you have 6-person teams, and you have 9 teams, that’s only 54 people. The teams don’t have to all be connected, as in the small world network here. Some teams are more connected than other teams.

Can you really track all the people on your program and know what the heck is going on with each of them? No, not when it comes to their code or tests or features. Never mind when it comes to their human-ness. I’m suggesting you not even try. You track enough of the other people do to be able to finish your work. Some people are well-connected with others. Some are not. This is why communities of practice help. (This is why lunch rooms help even more.)

What you are able to do, however, is ask a question of your network and get the answer. Fast. You cooperate to produce the shippable product.

Technical Program with Communities of Practice

You work with the people on your team and maintain relationships with a few other people. That’s what small world networks do. That’s why communities of practice work. That’s why the rumor mill works so well in organizations. We have some well-connected people, and a bunch of people who are not so well-connected. And, that’s okay.

Here’s the key point: you don’t have to go up and down a hierarchy to accomplish work. You either know who to ask to accomplish work, or they know who to ask. Nobody needs to ask permission. There is no chief. There is no master. There is no hierarchy. There is cooperation.

What are the Risks in Programs?

Let’s back up a minute and ask what’s important to programs. Why are there standups in a team? The standups in a team are about micro-commitments to each other. They are also a way to show the status in a visible way. They help us see our risks. We can coordinate our features and see if we have too much work in progress. We ask about impediments.

That’s why the Scrum of Scrums got started. All excellent reasons.

If you think about what’s risky in programs, every program starts with these areas of risk:

• Coordinating the features, the backlog among and between the teams.
• Nurturing the architecture, so it evolves at the “correct” pace. Not too early so we haven’t wasted time and energy on it, and not so late that we have technical architecture debt and frameworks that don’t work for us.
• How to describe the status in a way that says, “Here is where we are and here is how we know when we will be done.”
• How to describe our interdependent risks. Risks can be independent of features.

Your program will have other risks that are singular to your program. But the risks of managing features among teams; coordinating architecture; explaining status; and managing risk—those big four are the big issues in program management.

So, how do we manage those risks if I claim that Scrum of Scrums is a hierarchy and doesn’t work so well? Let’s start with how we manage the issue of features in programs.

Programs Need Roadmaps

Programs need roadmaps so that the teams can see where they are headed. I am not saying the teams should implement ahead of this iteration’s backlog. If the teams have a roadmap, they can see where they are going with the features. This helps in multiple ways:

• They can see how this feature might interconnect with another team’s feature
• They can see how this feature might affect the architecture
• They can create product backlog burnup charts based on feature accomplishment

In programs, teams need to be able to look ahead. They don’t need to implement ahead. That would be waste. No, we don’t want that. But looking ahead is quite useful. If the teams are able to look ahead, they can talk with their product owners and help the product owners see if it makes sense to implement some features together or not. Or, if it makes sense to change the order of some features.

When I get to large programs, where several teams might work off the same backlog, I’ll come back to this point. I realize that several teams working off the same backlog is not restricted to large teams, but I have a backlog for writing too, and I’m not addressing this yet.

A roadmap is a changing document. It is our best guess, based on the most recent demo. We expect it to change. We ask the program product owner to create and maintain the business value of the roadmap. We ask the product owner community to create user stories from the phrases and words on the roadmap. The teams can see which release the features might occur in, and they can see which features they’re supposed to get done in this release, and most importantly now, across the program.

Some of the words are not anything like stories. Some might be close to stories. The items on the roadmap close to us in time might be closer to stories. I would expect the ones farther away to be a lot less close. I would expect them to be epic in size. It’s the entire product owner community job to continually evaluate those phrases and ask, “Do we want these? If so, we need to define what they mean and create stories that represent what they mean.”

I don’t care what approach the product owners use to create stories from the roadmap. But the roadmap is the 50,000 foot idea. Only the quarter that we are in has anything that might resemble stories.

Oh, and that big black line? That’s what the teams need to complete this quarter. Anything below that would be great. As the teams complete the stories, the product owner community reassesses the remaining stories on the roadmap. Yes, they do. It’s a ton of work.

Once you have a roadmap, the product owners can create user stories that make sense for their teams. The program product owner works with the teams, as needed.

Since the teams are feature teams, not architecture-based teams, they can create product backlog burnup charts. Now, you can tell your status by seeing where you are in the roadmap. Note that you do not need a Gantt chart. You have finished some number of features, ranked by business value. You have some number features remaining. You can finish the program at any time, because you are working by business value.

Oh, and you don’t need ROI. You never try to predict anything. You can’t predict anything for a team, and you certainly can’t predict anything for a program.

Programs Need Architecture Nurturing

I am a huge fan of evolving the architecture in any agile program. Why? Because for all but the smallest of projects, the architecture has always changed. Now, that does not mean I don’t think we should not think about the architecture as we proceed. What I like is when the project teams implement several features before they settle on a specific framework. This works especially well in small and medium-size programs.

Just-in-time architecture and evolving it is a tough thing. It’s tough on the project teams. It’s tough on the architects. It’s so much easier to think about a framework (or frameworks) first and pick it, and attempt to bend the product to make it work. But, that’s how we get a pile of technical debt, especially in a complex product, which is where you need a program.

So, as much as I would like to pick an architecture early and stick with it, even I force myself to postpone the architecture decisions as late as we can, and keep evolving the architecture as much as possible.

What is the Most Responsible Date for Architecture?

Now, sometimes “as late as we can” is the second or third iteration. But in a medium size program, the most responsible date is often later than that. And, sometimes the architects need to work in a community, wayfinding along with the feature teams. Did you see in the roadmap in Q1, where we needed a platform before we could do any “real” features? If you have a hardware product, sometimes you need to do that. You just do. But, for SaaS, you almost never do.

This means I ask for architects to be embedded into the project teams. I also ask for architects to produce an updated picture of the architecture as an output of each iteration.

Can you do this on your agile program? If you have tests to support your work, you can. Remember, agile is the most disciplined approach to product development. If you’re hacking and calling it agile, well, you can call it anything you want, but it’s not agile.

Explaining Status: The Standup, By Itself is Not Sufficient

When you have a small program, and you have Scrum of Scrums, the daily standup is supposed to manage all four of these issues: how the features work with the teams, how the architecture retains its integrity, what the status, and what the risks are. In a medium program, that daily standup is supposed to do the same.

Here is my question: Is your daily standup, for your Scrum of Scrums working for you? Does it have everyone you need? If so, fine. You don’t need me.

But for those of you who are struggling with the hierarchy that a Scrum of Scrums brings, or, if you think your program is proceeding too slowly, you have other options. Or, if you need to know when your program will be done, you need agile program management.

One of the problems when you have a medium program is that at some point, the number of people who participate in a Scrum of Scrums of teams starts to overwhelm any one standup meeting. The issues you have cannot be resolved in a standup. The standup is not adequate for the problems you encounter.

(Remember, what was Scrum designed for? 5-7 people. What happens when you have more than 7 teams? You start to outgrow Scrum. Can you make it work? Of course you can. You can make anything work. You are a smart person, working with smart people. You can. Should you? That’s another question.)

Asking “what did you complete,” or even the old “what did you do since our last standup” is the wrong question. The question is irrelevant. As your program grows, the data overwhelms the ability of the people to take the data in. Especially if the data is not useful. Are you doing continuous integration in your program? If so, you don’t need to ask that question in your program.

Once you get past five teams, what you did or what you completed is not the question. You need to know what the obstacles are. You need to know what the interdependencies are. You need to know if deliverables are going to be late. That’s program management.

We’ll carry on with program management in part 3. This is long enough.

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

Technical Program with Communities of Practice

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.