Location, location, location!

They say there are three important characteristics of real estate: location, location and location. The same is true, I think, for the characteristics of a scrum team. Where they are located has a profound effect upon their success and productivity. Agile advocates recommend collocation of a software development team and proximity to the customer.

This isn’t some whimsical notion, or a cunning anti-outsourcing ploy. It advocates this because it works. We have been trying to build software in a somewhat predictable and satisfactory way for a handful of decades now. We’re finally learning enough to understand what works. And what works can be summed up in a few sentences (hint: read the agile manifesto). With respect to scrum teams and their location, it comes down to:

• they need to all be together
• yes that includes their scrum master
• yes that includes their product owner

The idea that agile software teams can be twice as productive as old school waterfall teams, maybe even 5 or 10 times as productive is, unsurprisingly, highly appealing to those who manage development teams for a living.

But here’s where things get weird.

Before IT executives were paying attention to agile, they were paying attention to off-shoring and outsourcing. These appeared to offer a way to substantially reduce labor costs associated with software development and other IT activities. Software engineers in Eastern Europe cost less than Western Europe or the USA. And those in India cost less than their colleagues in Eastern Europe. You can go further still, to China, where engineers cost even less. It’s probably only a matter of time before someone sets up a militarized compound campus in a failed African state and you can get engineers for who knows how little.

Irrespective of location these are all potentially good engineers, and this pursuit of cheap labor is not, in and of itself, the weird part. In a globalized world of free trade it’s inevitable.

What’s weird is when people blindly ignore one of the most important principles of agile software development (locate your team altogether in one place with your customer) and try and distribute software development teams across the globe. That’s trying to have your cake and eat it too.

There are some folks that try and suggest, perhaps with their consulting fee in mind more than anything else, that this is just a reality of today’s globalized marketplace.

I understand to some extent how they are OK with that, but to me it’s just a sitting-on-the-fence response that avoids calling out the stupidity that is taking place. The cognitive dissonance produced by the equally dogged pursuit of agile adoption *and* offshoring is at times almost painful.

Scrum teams have the potential to reach 10x productivity of conventional teams. You’re not going to do that though without dedicated people acting in a motivated fashion. You’re not going to get that with a distributed scrum team.

Let’s say your business has its center of gravity in a high labor cost country like the US. And you have a software product that you need to develop for that business. You have quite a few choices how you go about this: scrum or non-scrum, team based in the same location as your business's center of gravity, offshore, outsourced or some combination thereof..

Let’s assume we’ve decided we do want to use scrum, so we can eliminate the non-scrum approaches. Now, if we’re to be responsible about this, we should be considering a couple of things:

• how can we develop this product economically; that is getting the most product out for the money invested
• how can we develop this product effectively; that is making the best product we can, getting the customer what they want

Now those salaries in low-cost labor countries that are maybe ~1/5th the amount of their high-cost labor country counterparts do look pretty tempting: “Dude, they could be 5 times slower and it still would cost the same.” Kind of. Ignoring infrastructure, opportunity costs, dissatisfaction from lateness, reduced quality due to misunderstood communication etc.

Hmm. Maybe we can mitigate the risks of them being so far from the customer by distributing a team: "Let’s have some talented senior people in the high-cost labor country, and augment that team with lower cost labor. Yeah. That’ll be the best of both worlds." Except of course you’ve now pissed off your talented people by asking them to play babysitter. And having to accommodate early morning calls. Or late night calls. Oh, and with that immense time zone difference? There’s no chance for them to really chat and help each other out. The high bandwidth face to face communication of agile isn’t helping here at all. I suppose you could fly people around all the time. Soon going to start eating into the big pile of cash you’ve “saved” though.

Double hmm. So on the other hand, what if we focused solely on staffing a team with people where the actual business is that needs the software. Yes, a team in the high-cost labor country. But concentrate on getting their productivity up to that 5x level? Well then you might say, in many ways, they cost no more than the low-cost labor staff. But it’s better even than that. They have a full sense of ownership, they’re engaged. The customer is happy, they are able to work with the team to get just what they want. No more telephone game and lost details thanks to ambiguous email messages. Not only this, but they get it 5x faster. Oh, and we don’t need that expensive infrastructure to support developing software in two places. Holy crap. How can this *not* be the right way to develop software? Anything else is missing a chance for competitive advantage, is being financially irresponsible; is, frankly, stupid.