Can distributed teams be agile?

In a recent blog post, Tobias Mayer observed that one of the hottest topics around is how to do agile with geographically distributed 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.

Tobias’ main point is that we should question the assumption that we have to work with distributed teams:

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.

From my experience, I think Tobias is absolutely correct on both counts. Whenever I’ve heard someone ask about making agile work with distributed teams, the first response is that it can’t; teams need to be collocated. And invariably, the person posing the question replies that the decision to have a distributed team is out of their hands. And in my experience, most of the time, the decision to embrace off-shore resources really is out of the practitioner’s hands. The practitioner can question the wisdom of distributed team all he wants to no avail.
But you know, this is just a subset of the general issue with offshore development. The exec who makes the decision sees money: I can hire two engineers in X for the cost of one engineer in Y. But the practitioner has to deal with the reality: two engineers geographically removed from the rest of the team are hardly as productive (or less so) than one collocated engineer. Plus, the company is paying gobs of money to fly people around the world to manage the arrangement.
As the outsourcing situation matures, my prediction is that decision makers will begin to understand the actual value proposition of outsourcing, and we’ll see more collated teams again.
If the problem lies with distributed teams, not with some fundamental disadvantage of off-shore development itself, then the people advocating collocation had better be prepared for this eventuality: their company may just decide to collocate teams by moving an entire development effort off-shore. I know of one company in Austin that has moved all of its development to India, and my own company has relocated all development for one product from the US to Singapore.

Agile testing with globally distributed resources, part 2

In my previous post, I explained that our company’s team in Singapore performs what we call enterprise testing, and I outlined some of the steps we’re taking to help the enterprise testing team to support the agile R&D teams more effectively.
In this post, I’ll share some specific practices that we’re working to implement.

Continue reading Agile testing with globally distributed resources, part 2

Agile testing with globally distributed resources

Here at Borland, basic functional testing is the domain of the agile team that develops the functionality, while a dedicated QA team in Singapore is charged with performing what we refer to as enterprise testing–performance and scalability, integration, localization, etc.
This post outlines some of the changes that we’re implementing in regard to the enterprise testing group.

Continue reading Agile testing with globally distributed resources