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.
- 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.