Scale Agile With Small-World Networks

Some organizations, when they think of programs (a collection of projects with one business objective), think of many teams, each with Scrum Masters or project managers. That’s one way to scale agile. That’s scaling up. It creates a hierarchy. Hierarchy can slow you down with centralized decision-making, coordination, and communication. Even though you might not, the team members often think you have to use the hierarchy to communicate.

You can make this work, especially if your program is about a dozen teams or fewer. Hey, you’re a smart person. You can make anything work.

There is a better way.

Instead of scaling agile up with a hierarchy, you can scale agile out with networks of teams. You don't need tons of management or a rigid hierarchy. You do need responsible people who want to do great work.

Harness the power of small-world networks, the informal networks, that already exist in your organization, to work for you.

Small World Networks

If you know about the “Six Degrees of Kevin Bacon” meme, you know about the small-world network. If you’ve ever searched for anything on Wikipedia, you’ve used a product built by a small-world network. That's where people who don't know each other volunteer to help build and refine the world's largest encyclopedia. People with specific expertise add small bits of information over time. What's amazing is that you don't need too many people or too much time to create very useful information. That's the power of the small-world network.

How can you create and use these informal networks, the small-world networks in your agile program?

Create autonomous feature teams. Create named feature teams that reflect the name of the feature set they work on. The feature teams are autonomous in the sense that they take responsibility for their feature set. They also collaborate across the program.

For example, if you have an email feature set in your product, a team might deliver the “forward email” feature. That feature is small and valuable.

Other teams might want to know when that feature is available, because they might need to use it when it's available. That's the collaboration part.

Ask teams to take a product, not a system or application focus. It doesn't matter if teams deliver internally or externally. Think of the system as a product.

Product Thinking Can Change How People View Their Work

When teams focus on delivering a product, they see these outcomes:

• Other people across the program will associate this team or set of teams with a specific feature set. Everyone knows who to ask for help about the features.
• When the teams work by feature, each team can integrate each small feature as they complete it. If you don't already have continuous integration, you work towards it.
• With a product focus, everyone expects first the features, and then the entire product to work.

Invite collaboration. Explain, “You are the ones who know the technical details of the features. You know when the features need to integrate. Please start the conversations among you, the feature teams. Let us, the program team, know when we need to support you.”

Create exploration containers, such as communities of practice. When you create open communities of practice for developers, testers, architects, etc., people find the communities they need. You may have to seed these communities with food and initial activities, so people see why they should participate. In these communities, people can share what’s working for them. You want everyone’s first allegiance to be to their feature team. However, you want people to share what’s working and what’s not working, so the feature teams can learn from each other.

Small World Networks Distribute Control

If you use small-world networks, you will discover that the program teams can manage by exception. The larger your program is, the less centralized planning works. What works for three to six teams falls apart at 15 or more teams. Having the feature teams coordinate at the team level makes much more sense.

Now, some of these suggestions might not make much sense to you if you are having trouble delivering value every few days, or if you don’t have feature teams.

If that describes you, don't despair. I have many pragmatic suggestions for alternatives in my upcoming book, Agile and Lean Program Management: Scaling Collaboration Across the Organization. And, look for more blog posts on Managing Product Development.

Where Johanna is Speaking

If you liked this article about scaling agile, let me remind you about my November workshops in Israel. The scaling agile challenge is agile program management. I'm teaching a workshop about agile program management, along with several others, in November. See for the schedule. Don't worry if you are not “totally” agile. I have alternatives for you, too. Please do join me.

Oct 23 Webinar, Agile Hiring: It's a Team Sport

I also have two new coaching programs available:
* Agile Program Management Coaching for those of you who want specific coaching for your agile programs.
* Project Portfolio Coaching for those of you who are suffering with too much to do.

 New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.