Big Org, Small Bandwidth

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.
  

Through this Mesh network, a company can produce a much more adaptive communication structure that diseminates knowledge more reliably, is at less risk of a communication failure, and addresses the issue of limited bandwidth in a way that scales to any sized company. Best of all, it fits with Agile principles of self-organizing, and removing waste in a way that enhances your business.

Ideas - Being Heard

I learned something about myself, about job satisfaction today. I learned about my ideas, and how sensitive I am to how they are received. The situation was simple, and the guy who revealed my sensitivity is a great guy, so he'll hopefully forgive me for using him in my example.

We've been talking about doing a team outing/team building exercise. Our CTO, asked for ideas. I felt strongly about our activity being of value to the company, and that it also be fun and socially acceptable for the group. Falling backwards into the group in a trust game wasn't going to cut it for these guys. So I spent a couple of hours on it, now I had a time investment and an emotional investment in this idea generation.

I came up with two, a treasure-hunting service that focused a lot on the team aspects I thought were important, and a cooking class since Adam had suggested dinner as part of the exercise (I figured we'd work together at a common goal - getting fed - and solve our food challenge all at once). I sent the ideas off to Adam, who then forwarded them to the team.

A member of the team responded with "I vote against a cooking class." and then went on to suggest his own activity.

I was devastated. I didn't want to suggest any more ideas. I was done with helping the activity. I was turned off, tuned out, I wanted no part. But I didn't know it. I knew that if you asked me about it I felt poorly, but I didn't understand why or what the extent of the affect was. I thought it was just another email until later, when our CTO asked me to just send those ideas to the group on my own, no reason to make him the bottle neck. What he asked me to do made me think about why I didn't do that in the first place.

As a group, we're young, naive, new, green. We don't know how to talk to each other so that we get our ideas out and heard. In this situation, my idea went out, it was read, but not heard. The recipient dismissed it without really chewing on it, thinking it over, and replying with why it didn't work for him. Was it that he doesn't like classes? Was it that he doesn't like fire? Is he on a specialty diet and doesn't want to impede others? I have no idea. What I do know is that his message implied "Will, your idea is bad, so bad I can't even build on it or respond to it." Ouch. I know the sender didn't mean it that way, but that's how it made me feel.

Now put me in a room, and ask me for an idea. How likely do you think I will be to share my thoughts? If I say something, it'll probably be safe, something that has already been established as accepted by the group. My ability to help the group innovate, to be creative, has been destroyed over time on an unconscious level by experiences like the one above.

But I do still contribute ideas. I do it because it is rewarding to be heard - it's why I like working in small companies where everyone has a voice. And there are people who hear me, like our CTO, like Matt. When I say to them "I have a crazy idea [blah blah blah]!" they listen and say "That is crazy, but I see where you're going, what if we..."

And that's how I know I'm being heard. That's how I know that they're communicating. That's how I know they understand me. And from that point, we could go anywhere.

Location, Location, Colocation

In my experience, the team that "eats together, wins together", or something along those lines. It's tough get the most out of a team if you're not working together. The problem is not solved simply by having the team in the same building, they have to be in the same room, without full walls. When working with Matt, we had half walls, you could be sitting, and see the faces of everyone, but your got a little privacy for what was on your desk, or on your screen.

The problem compounds when part of your team is in a different timezone. Staying in the US with as much as a three hour gap is detrimental to an eight hour work day, but what if your company has paired you up with an off shore team in India? Sure, it seems great to have people working on a project nearly 24 hours a day, but the reality is that there's no reason four people can't do the same work in an eight hour window as two can in one window and another two in a second window. The detriment is when you need a question answered. For instance, let's say it's Friday morning, and you just checked out the latest code from source control (you do have source control, don't you?). You were all set to finish up a user story today before going home for the weekend, when you realize that your counterparts in India decided to refactor three classes. Nothing is where it was before, and they didn't send you any kind of help on how to use the new set up. You could:

• Call them. The company is more than willing to foot the international phone bill.
• Send an email. You can be a little more clear and concise to help the communication barrier.
• or you can spend the time yourself to figure out what the hell is going on.

You best option is surprisingly the third option (or you could work on something else). Because of the time change, team India has already gone home for the weekend. You'll get your response sometime on Sunday. It'll be Monday before you can get anything done.

So the question you have to ask yourself is this: If it takes that long for a team member to get work-related information, how in the world can I expect the team to develop the comaradarie and trust it needs to be highly effective? You simply can't.

Occasionally, I was brought on to help interview candidates. I knew someone else had an interest in seeing if the candidate could write code, so I never asked many technical questions. I was always after the team fit. "Can I talk to this person?" "Does this person speak in a way that is constructive?" "Will this person be able to learn from and teach me?"

This often showed itself with a much simpler question: "Does this person laugh at my jokes?" If she didn't laugh, I knew right away that we'd have trouble communicating. It might have been a language barrier, or a subculture barrier? Sometimes my humor is lowbrow, but that's the way the team works on a daily basis. It happened more than once that I said a person was not a good match, "a 'No Hire' situation" as I now say in the hiring market, but I was told that culture fit isn't as important as I made it to be. In each case, the person hired was not successful in his/her job (and was usually let go or repositioned shortly after). I'd take someone eager to learn with a good team fit over a brainiac-thorn-in-my-side any day.

I've gotten slightly off topic but the point is that the team has to work together. In an Agile software environment, a team is not a group of people who meet once a week. It's a group of people who share the same work. We all own the same code, the same successes, the same failures. This isn't true in other departments where victories are the result of an individual's efforts. This is also why it's tough for management to understand why you need a big room with all of the team together all of the time. I'm not saying there can't be a side room for personal phone calls, but when you're working, you need instant access to the knowledge of the team. You need to be able to collaborate at any point in the day. You need to know these people, and know that you can trust them to do their job, and ask for help when they need it, and ask early.

The key is to have a physical presence in the same area as the rest of the team. The barrier to pop your head up and ask the guy on the other side of the table is insignificant to looking up a number, picking up the phone, dialing the number, waiting for the off-site guy to answer, and so on. A man in Waterloo worked around this disparity by getting a robot with a monitor, speakers, and web cam to drive around the office. He may not have been in the office himself, but all the components for people to interact with him quickly were there. If a time change is an obstacle, then consider shifting your office hours to match, devs love to sleep in, but families can throw a wrench in this work around. If all else fails, just split the team. The people that can work in the same space at the same time are one team, the people on a different schedule/location form a different team, or work solo. In the end, your teams need to be with their team mates, and they need to be able to leverage those team mates at the drop of a hat.