Thursday, June 24, 2010

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.

Friday, June 11, 2010

Many benefits are touted for those who chose to adopt an agile approach to software development. Some are more typically cited by coaches and tool vendors as a kind of sales tactic:

your teams will become more productive

you’ll ship business value sooner

customers will be happier

you won’t build features that aren’t needed

Others, perhaps less vigorously or frequently stated include:

development proceeds at a sustainable pace, not burning out your staff

quality typically improves, particularly if one adopts a lot of the supporting technical practices advocated by XP

for most people, it’s a more fun, interactive and collaborative way of working leading to higher job satisfaction

the time needed for feature development becomes more predictable

There are more than these but for the purposes of this blog post these will suffice. The question I want to ask (and answer) is, when adopting agile, where should the emphasis be? What benefits should we champion and pursue?

From the perspective of managers and company executives, those items in the first list really resonate. This is understandable; they correspond with responsibilities that those people have. But how exciting are they for those people actually on the teams that have to do the real work of creating working software?

Well, I would argue probably not very exciting at all. I think it’s a misconception, but the “your teams will become more productive” and “you’ll ship sooner” benefits are often interpreted by teams first encountering agile as “you want me to work even harder!?”

This reaction can be compounded with the introduction of daily stand-up meetings. “Oh, so now you want to micromanage it and check in on my progress every day?”

Both of these interpretations are (thankfully) incorrect. This is not the motivation for agile done properly and not what should be going on. It’s easy to see though how this misconception could arise when so much emphasis and commentary exists about those two benefits and how often they get trotted out.

This is why I would argue that the sensible approach is to focus on the benefits in the second list above. Emphasizing changes that bring these benefits are much more appealing to those people actually doing the work. They’re a much more humane and rewarding set of ideas. In my opinion, and experience from the last year, agile done right will really focus on the teams. On empowering them to control much more of the work and how it gets done.

I know that I, as a team member, would feel much better knowing that sustainable, predictable development was valued. I’d feel much better that the increased transparency of Scrum would serve to highlight impediments to my work, that would get the attention they deserve and promptly remedied. I’d love knowing that the organization valued quality and craftsmanship in software development. I’d enjoy not having to estimate every last detail in fractions of hours. I’d almost weep with joy at not having to comb through hundred page specifications of poorly written and ambiguous requirements documents.

Best of all though, focusing on these things, and aiming to unlock that second list of benefits will, I firmly believe, lead to those benefits in the first list. It’s inevitable.