July 18th, 2008
Distributed Teams are not Teams
Many Scrum practitioners these days are working hard to come up with the best way to make Scrum work in distributed (usually off-shore) environments. There are many articles being written on this topic, and many submissions to the major Scrum and Agile conferences. They all say something similar, we know that co-location is ideal, but the reality is… and then go on to offer “solutions” (read work-arounds) for the non-ideal, real world situation where team members are scattered around the globe.
It is interesting how the phrase “the real world” is used almost as a weapon to wield against the idealist: yes, it is all very well to say that teams should be co- located but that is not how people actually work in the real world. We seem to forget that reality is not something that is imposed on us. Reality isn’t just there; we create it. The phrase “the real world” is akin to the phrase “it’s just the way we do things around here”. Both should be challenged with a healthy dose of skepticism and a steady barrage of “why” questions. Just because it is, doesn’t mean it has to be.
Distributed teams are not teams; they are at best a collection of people who communicate regularly. But communication is not collaboration; it is a poor relation, weak and insipid in comparison. A distributed team cannot create the kind of energy that comes from human eye contact, from shared spontaneous laughter, from physical touch. True collaboration requires all five senses, not just a voice over the telephone, or a second-hand video image. And email… don’t even go there. Distributed teams require managers, and thus can never be truly self-organizing. Time differences and delayed response times inevitably slow down conversation, hold up decisions and ultimately cripple agility. Distributed teams can never be truly Agile. So let’s stop pretending.
Step back for a moment, and rather than assume we have to take Scrum to anyone who asks for it, let’s look at an alternative. Try a thought experiment: if all Scrum coaches refused to work with organizations who insist on having distributed teams, what would happen? My guess is that those companies would all go under very soon, proving the ridiculousness of the distributed team model. These companies are requesting Scrum exactly because they are struggling, yet they are rarely willing to remodel themselves in an Agile way. They want it all: cheap labor and high yield. Not so different from third world child labor industries. Maybe we should simply say no. No, we are not going to support this madness. Force-fitting Scrum into such environments may keep them afloat a little longer, but ultimately they are headed for failure. The model is ugly, painful and undignified, it undermines human relationships and is certainly sub-optimal.
Scrum believes in fast failure: “Scrum will help you fail in thirty days or less”, said Ken Schwaber in his oft-quoted elevator conversation. Our job as Agilists should be to speed up the failure of the distributed team model, not to prolong its agony. Once the organizations that support it are dead, we can begin building new kinds of companies, democratic companies modeled on true Agile principles: ideal ones, not half-hearted ones. The sooner that happens the better.
To whet your appetite here are a few articles about companies that embrace co-location, self-organization and democracy:
Kind of like Kindergarten — Menlo Innovations
Engines of Democracy — The General Electric plant in Durham, NC
Who’s in charge here? No one — Semco, Brazil
July 18th, 2008 at 7:58 am
The ScrumDevelopment online group discussion on this topic begins here.
July 18th, 2008 at 8:13 am
I completely agree with your post. The company for which I work has all of its developers over a thousand miles away from the bulk of its actual clients. We make quarterly trips to watch the processes and meet the users, and take our time to discuss with them the daily tasks they perform and how we can improve our software to ease their jobs and improve the quality of their performance.
Having worked with the company for a length of time before actually meeting with the clients, I found that the difference between emails and face to face contact is immeasurable. I thought I knew so much until I actually talked to users and watched their daily processes; my performance has since improved enormously, and has been noted by our users and my supervisors.
The Scrum process is a wonderful tool and solution for users, but with a lack of knowledge, can easily be abused by managers looking for a quick and dirty way to “improve” their company. Your comparison to child labor was not far off.
At any rate, a toast to your post, thanks for the read and the great links.
Cheers,
Cat
July 19th, 2008 at 8:13 pm
Hi, Tobias!
I used to agree completely with this, but have since coached exactly one distributed team that really is a team. They are a group of people who worked together for years physically, live just a couple hours’ drive apart, and have strong relationships. They get together physically as needed, circa once a month. The rest of the time, they work virtually, with a lot of audio conferencing and virtual pair programming. They know this isn’t ideal, but strongly prefer it to uprooting their families to move closer together.
I’d still agree that companies trying to build virtual teams are all likely doomed to fail, and if any succeed they will pay a large price in productivity and agility.
When they haven’t even tried a collocated agile before trying some distributed variant, I think it’s an especially large mistake, as they quite literally don’t know what they’re missing. Often, they’re trying to get the benefit of change without doing any of the work, like somebody who buys running shoes and a track outfit, and then just wears those while sitting on the couch.
Still, there are (very rare) examples of good distributed teams, and I think the real problem is people making some change in a half-assed and illusion-driven way, rather than distributed teams as such.
Response: Hi William. Yes I agree with you. When team members know each other as people (not just employees), have worked together physically, established a rapport and trust one another then working in a distributed fashion, by choice can work very well.
As you say, the problem is not distributed teams as such, but people not wanting to do the real work of change.
July 27th, 2008 at 7:35 pm
I love this post, Tobias. We seem to forget that we can usher in a new set of “given circumstances” to change our realities. Reality is the result of people and their decisions. People can change and they can also change their decisions. I have also had an experience like William’s, and I also agree that we need to keep pushing the ‘general public’ to take an introspective look at how they’re running their businesses.
August 5th, 2008 at 4:30 pm
These statements are hogwash and arrogant. Let’s see. So if I don’t use scrum the way prescribed here, then my reality is not quite as good as yours? That’s just nonsense. A team does not become one because they are “co-located”. They become a team because they can read each others minds, because they complement each others talents and because they have a strong sense of commitment to a singular vision.
To imply that I should refuse work or revert to some less adaptable process is ludicrous unimaginative. I also find your inference that management is somehow to blame. Take a little responsibility, find some imagination and find the right people. If you can’t get distributed teams to work effectively and efficiently then perhaps you need to look inward rather than sticking out your chest and refusing to work at all.
October 5th, 2008 at 10:20 am
I am curious if and how you would use Scrum or similar agile methodologies to manage open source software projects, where usually the core developers are distributed all over the planet.
October 5th, 2008 at 2:04 pm
Harold, I would certainly encourage self-organization over centralized control (which seems to happen anyway in most open-source implementations — e.g. the Bazaar model). But I wouldn’t call it Scrum. Open Source has always been very successful without Scrum. It doesn’t need it. Command cultures, traditional businesses relying on top-down, mechanistic ways of thinking and working, those are the places that need Scrum.