Offshore Agile Development
There are two significant trends in the software development market that have been in full force for more than a decade—with no end in sight. First, companies in high-cost-of-labor regions are feeling pressure to reduce costs. Second, the levels of programmer capability and quality of enabling infrastructure in low-cost-of-labor regions are rapidly improving.
That’s why there’s been such a trend toward outsourcing aspects of software development—why it has been increasing and why it will continue. From a waterfall-process point of view, there are basically four models of outsourcing reflecting “how much” of the work is being sent outside the (local) team.
Agile development processes have been embraced in many companies, primarily because of the first trend—the pressure to reduce costs—but it manifests for many companies as the pressure to fail less often, build better products, or get to market faster. Those are all effective ways to be more competitive, but choosing an agile process is just a lower cost approach to being more competitive.
You could “throw people at the problem”—which is more expensive and less likely to work—which also means it is much more expensive to throw enough people at the problem to overcome the odds of failure.
Companies are not limited to only choosing a single approach to competing in this market. In 2006 Martin Fowler wrote an outstanding and in-depth article about using both agile processes and distributed teams at the same time and then revisited the topic in 2011. He found the guidance to still be relevant five years later.
This is harder to do, but so is competing just as effectively without distributing your team, which means cost is part of the equation. Some would argue that if you distribute your team, you better go agile.
The success of any team relies on effective communication. Agile is built on the bedrock of the necessity of more communication than waterfall processes require. This additional communication supports iteration and feedback at both the high level and the very low level. Think of pair programming, the fastest and most data-rich feedback loop, as the lowest level. Prototyping, demoing, and eliciting feedback from users are at a higher level.
The challenge with spreading teams geographically comes when you shift time zones. You introduce delays, or impedance, into the flow of these communication cycles. It is the temporal displacement that changes the model (relative to collocated teams), not absolute distance. Imagine if you were programming and had to wait twelve hours to find out if your code compiled—that would be a recipe for failure.
So, you have to figure out which interactions will have the delays baked-in and which can happen in real-time. You can have just the development offshore, or both development and design, or completely outsource all of the technology work (that’s what your CEO does).
Fowler’s article provides many valuable lessons learned and tips for making geographically distributed teams effective, even with the high-communication dynamics of an agile process and the large-communication lag of temporally distributed teams.
