Small-world networks: a lightweight alternative to SAFe for scaling agile

You’ve probably heard of a number of ways to “scale” agile in your organization: SAFe, DAD, Scrum of Scrums, and LESS, to name several popular frameworks.

The problem with frameworks is that they don’t account for your context, and they increase management and hierarchy. With hierarchy comes bloat—many meetings, remote problem solving, and what the teams call “interdependencies.” It’s a mess.

Instead of bloat, wouldn’t you prefer resilience?

Program management with small-world networks can provide that resilience. Teams can solve problems themselves. You can have fewer meetings of shorter duration. The teams—as well as management—can see progress.

First, I’ll explain what small-world networks are. Then I’ll illustrate how, in my opinion, they scale agile much better than the popular frameworks.

What’s a small-world network?

Small-world networks are our interconnections with people not on our team, not in our direct line, and not among those we directly work with all the time. If you have ever asked a question across your organization and someone outside your department ended up providing the answer, you used your small-world network.

We use small-world networks all the time. Small-world networks of people build, maintain, and upgrade Wikipedia, the world’s largest encyclopedia. These people do not know one another. They have one overriding purpose: to present the best information about a topic in the best possible way. They connect as they work together. They don’t have to connect permanently. They connect to better the reading experience for others.

Think about your work now.

If you have a question or need some information, what do you do? Let’s assume you want to change a product’s pricing because it’s much more valuable now that the team has added features. You ask Sue in Sales. She agrees with you that the price should be changed. Even though she’s a director, she doesn’t know how to change the pricing. Sue refers you to Larry in Legal. He’s not sure either, so he says, “Let me get back to you.” Larry asks Frank in Finance, someone you don’t know and would not have considered. Frank responds with the answer you need.

Just like your connection to Kevin Bacon, you have less than six degrees of separation from the person who knows the answer to your question.

You all want to help the organization succeed (your purpose). Everyone uses his or her initiative to send questions across the organization to help one another (autonomy). Everyone learns more about the problem in question and gains more knowledge (mastery).

Your organization’s small-world network is the fastest way to move relevant information around the organization. Think of the most recent rumor you heard. How many people—and which people—did that rumor move through? That’s your current small-world network. Just imagine how you could use that network on a large effort.

Program management facilitates work across the organization

If you’ve read any project management literature, you may be familiar with the term “program management.” A program is a collection of several projects meant to deliver a valuable result. You might have a program of several software teams: a software program. You might have a program of cross-functional business people: the core team.

If your product is a smartphone, you might have several development teams working on the minimum viable software features of the phone. In addition, you need hardware and manufacturing teams to decide how the hardware and manufacturing will work.

The software teams run on a different cadence than the hardware and manufacturing teams. (I’m not talking about sprints, although the teams might use some sort of time-boxed approach to deliver value.) Because software teams can break their stories down into very small increments of value, they can deliver value daily into the code base.

The hardware and manufacturing teams might iterate on their designs, but they are not likely to deliver value every single day.

If you had five feature teams for the smartphone’s call processing, two teams for text, three teams for voicemail, and two teams for the platform, you would have a software program of 12 teams total. Using frameworks such as SAFe or LESS, you might need a Scrum master or project manager to gather the problems from the teams and elevate those problems to some sort of steering team. This team might have to meet every day in a daily scrum. That steering team would decide what to do and pass that information down to the teams. Inadvertently, these frameworks increase the number of meetings and the delay between when the teams find problems and when they can solve them.

Instead, imagine this scenario:

One of the call-processing teams realizes there’s an interrupt problem in the platform. They send an email to the platform team and post the issue on a program-wide wiki.

Call-processing team: “Found a problem in the platform. Here are the details.”

Text team: “Here’s the workaround we discovered last week. It might work for you.”

The call processing team can now continue.

Platform team: “Thanks for this scenario. We thought we had a fix and now realize it’s more complicated. Please keep using the workaround until we fix this. We expect to have something in three more days. We’ll let you know.”

The technical teams identified and solved this particular problem with no intervention. They incurred no delay due to hierarchy.

What if the platform team is stuck on this problem and needs help from someone outside the organization, but the platform team doesn’t have authorization to spend money? They would use their delegate to the software program team to explain the issue, what they need, and when.

Although the software program team has a (weekly or biweekly) meeting cadence, they don’t have to wait until their next meeting to solve problems. The software program team exists to solve problems the feature teams can’t solve by themselves. They can meet as a problem-solving team as often as they need to—and that meeting does not have to be daily.

Communities of practice enhance collaboration and problem solving

When one team discovers a problem, they might use their community of practice to solve it. A community of practice is where like-minded people gather to share knowledge.

Communities of practice are a form of knowledge management. All you do is get groups such as developers or testers together in a room, a wiki, or a chat application, and they discuss the cool or challenging issues that arose for them recently.

But you don’t have to worry about capturing this knowledge. The teams might learn faster if they are digesting it together in real time. Instead, consider the communities of practice as a way for people to make more connections across the organization. The more connections they have, the faster they can learn and identify and solve problems themselves. This will make your program more resilient.

Scale collaboration, not process

People live up—or down—to your expectations of them. When you ask people to collaborate with one another, they develop and use small-world networks. Imagine how well your program could work if you asked people to use their small-world networks and collaborate across the organization.

Small-world networks scale infinitely in nature. Your organization might have an upper bound, but it will be a higher bound than a hierarchical approach allows.

Instead of scaling agile, think about just using program management. Ask the teams to collaborate as much as possible across the organization. Then you can create a program environment that delivers valuable product faster without the bloat.

Are you currently using some of the collaboration styles of small-world networks? Intentionally or unintentionally?

Topics: Agile