You're using Scrum? Excellent! But now you're adding a new team and you want to stay connected so you're now going to two stand up meetings each day. Okay, that works. But what if you add another team? Two more teams? Five? Now you're either spending your whole day in stand up meetings (and that's a lot of standing up), or you're only getting part of the picture each day.You do some research and come upon this Scrum of Scrums thing. A representative from each team now makes up a new team and they have a stand up meeting. And this works pretty well until you've reached about fifteen teams. That's fifteen people giving updates about the progress of 100 employees. It starts to become an information overload. So you do what worked last time, and add another layer, a Scrum of Scrums... of Scrums (aka SoSoS or S3 because we're quickly running into the land of ridiculousness). You have successfully formed a tree network (see the diagram above from the Wikipedia entry on Network Topologies) and you have also managed to alienate yourself from all the people doing the work. *screeching brake sound*
You think to yourself, "But this is how business has always worked! Yet.. shouldn't the head know what the feet are up to?" You scratch your head because the tree network isn't making sense, and usually when a thing has this "smell" to it, it means you could be doing something better. "But I don't have the bandwidth to stand up with 15 teams, how can I possibly stand up with 50?" For that, I have a suggestion.
The real impediment is you as the department head. You don't have to know everything. There are some things you need to know, like projected release dates, and product backlog priorities, but these are things that you should be able ot easily get from your teams either electronically or by walking by their team space where they have their burn down charts posted. The people who need to know everything, are the people doing the work. Jim needs to know about the new Logging API so he doesn't have to rewrite one of his own. Bob needs to know that Sue has a problem with the parameters being passed to her function because she wasn't expecting NULL to be allowed. Dave needs to know that he needs to add upgrade the Linux servers to the latest Java VM to fix a bug Mark found, and the new employee, Mindy, needs to figure out where to download the third party DLLs from. If you're doing SoS or S3, somehow that knowledge has to not be omitted from being presented at the SoS, and then brought back to the team, to someone who might have a solution, and then that brough back to the SoS, and back to the original team.
You don't need to know all that, but they do.
And yet, those team members don't have the bandwidth to convey that information directly to everyone else any more than you do. We've tackled this problem of bandwidth in software plenty of times. When we can't push enough data in a cost-effective way between a server and the clients, we either a) get more servers and a domain controller to route traffic along the tree, or we make a peer-to-peer application like BitTorrent. We create a bunch of partially connected networks, using a part of the available badwidth of each user to create a very scaleable network that is more resistant to single points of failure, is cost effective, and still gets the job done.
I propose, that people, Scrum teams, can communicate the same way. If Team A always talks to Team B and Team C, and Team C talks to Team D, then all four teams are either directly or indirectly connected. Eventually, knowledge from Team A would propagate to Team D through Team C. This means that instead of a Tree network, we're looking at a Mesh network.
Goals:
- Allow the network to be self-managed. Teams should naturally work with other teams where there is overlap. But do give them the time and tools to form those networks. Maybe instead of having a cross-team standup every day, you provide those teams with lunch at the same time in the lunch room.
- Help reduce the degrees of separation. If Team A works with Team B, who works with Team C, who then works with Team D, A and D are very separate, and the chance of knowledge being passed from one to the other is very small. Do this only when it makes sense by fostering cross-team communication (assign them related feature sets, have an off0site with the two teams, etc). Ideally you'd want a Fully Connected network, but then you're out of bandwidth all over again.
- Identify "hubs", and participate in those stand up meetings. Some teams will naturally be more "social" because of the nature of their feature set, or by the makeup of the team membership. Hook into these teams to get a feel for what is going on day-to-day. Think of it as standing in Grand Central Station, you're much more likly to see someone from San Francisco pass through there than you are if you waited in Boonyville, USA.
- Don't let the connections stagnate. Some connections will always need to be there, but by forming new connections, now there's a chance for all of the knowledge to transfer to a new area within the company. Transfering members across teams who have strong bonds with their old team could serve you well in this area.
2 comments:
Over at InfoQ (http://www.infoq.com/news/2008/12/scrum-of-scrums-alternative) Chris Sims did a great article relating to this post. He points out that the SoS is very good for moving information up and down the organization tree, while the mesh as I've proposed, lends itself well to going across (left and right) in the tree. Perhaps both serve a useful purpose if the domain for each is restricted appropriately?
I saw the InfoQ piece and was interested to read your post to get the rest of the story. My impression is that the mesh network idea is just an idea at this point. It sounds reasonable. Have you tried this approach? If so, what worked well and what didn't?
Another question I would have about an organization that was having the severe degree of communication problems you describe is why haven't they been using other agile techniques for cross-team communication, such as information radiators and wikis and so forth? Since they aren't already using any well-known effective techniques to overcome their communication blockages, how can we expect them to adopt this new technique any more successfully? It would be human nature for them to continue to behave as they currently do unless they have an incentive to change. Without that sort of change, they won't take any better advantage of the mesh network than they do of other techniques already available to them. They will simply continue not sharing information.
Something else I noticed is that you show several network models, but you omit the one that represents human groups most closely: the small-world network. Organizations of humans tend to end up in a small-world configuration regardless of what shape management tries to force them into. If that happens in an organization that has tried to impose the mesh model, wouldn't it result in islands of information-sharing that are isolated from most of the rest of the organization? Have you seen that pattern in organizations where you've tried the approach?
Like you, I've noticed a problem with scaling the scrum-of-scrums technique. I don't think it's a question of how many teams, but of how many layers of scrum-of-scrums meetings that are required. Once we reach two layers, the whole thing turns into a giant game of "telephone." Corey Ladas proposed (and demonstrated) an alternative format in which each individual does not talk about the "three questions," but instead a facilitator walks the task board (the project one, not the individual team ones). Those who have something useful to say can speak up, but everyone doesn't have to speak so the meeting stays short. Since everyone is present, and not just one representative per team, everyone has a chance to hear the same statements. This is another solution to the inherent problems in scaling the conventional scrum-of-scrums format.
Post a Comment