Geoffrey Bourne has 11 years of experience in the financial IT field, successfully managing several globally distributed Agile teams in Mumbai, Bangalore, Hong Kong, Japan, and the U.S. He has worked at J.P. Morgan, Goldman Sachs and several start-ups. He has a B.S. in Computer Science from Washington & Lee University and is a certified Sun Java Developer and PMP. Geoffrey is currently a Vice President at a major financial institution in the New York Private Bank and Personal Wealth Management divisions and can be contacted at firstname.lastname@example.org.
In the early years of my technology management career, I practiced standard Waterfall/Software Development Lifecycle (SDLC) methodologies that all too often fell short as a tool to enable my team and I to effectively reach our objectives. The memories are still vivid: Mountains of unnecessary documentation and late-night project management meetings where the focus was discussing the SDLC's process rather than meeting our objectives.
So learning about Agile was a revelation. I still remember my "light-bulb moment" when reading a borrowed copy of Ken Schwaber's Agile Project Management with Scrum and realizing that there is a different way to look at how we deliver products. Schwaber's book is now my "Agile Bible" (not the borrowed copy). Since adopting Agile, my distributed development teams have risen to a new level of productivity and enjoy a more satisfying work environment. Regular, value-added communication and meeting project objectives are now our focus rather than navigating methodology.
Since finding success with Agile, it's no surprise that I've emerged as an evangelist of Agile's virtues. However, a few years ago my understanding of Agile was put to the test after a colleague challenged me to apply Agile to a team made up of distributed onshore and offshore members. Over the course of our conversation, I was cornered into admitting that Agile doesn't speak to a distributed environment. Instead, I realized that over the course of many years working with a distributed Agile environment, I unconsciously compensated for gaps by modifying practices…which begs the question, "Is Agile still Agile in a distributed environment?"
I experienced a re-awakening of my commitment to Agile at a talk given by Agile Scrum guru and co-creator Jeff Sutherland. Like my colleague had challenged me, a member of the audience asked Sutherland to apply Agile to distributed teams. Needless to say, Sutherland's response was similar to mine but with a lot less stammering! He, too, ran into inconsistencies with distributed Agile teams and worked around them by applying new processes and techniques that are not necessarily prescribed by the standard Agile process. All was right with the world again.
Realizing that there was a need to face concerns about applying Agile to a distributed team (rather than run from the challenge!), I began to coalesce and document my experiences in effectively running an Agile team within a distributed environment. And what did I find is my conclusion upon meditating on Agile in a distributed environment? Distributed Agile is still Agile, but with a twist.
A primary tenet of the Agile process is the co-location of the team. Ideally, developers sit only a few feet away from the Product Owner or business partners. This co-location typically facilitates several benefits of Agile: frequent communication and feedback, a sense of ownership, and team building. However, managers are often forced, due to budget constraints and corporate policy, to manage a distributed team comprised of both onshore and offshore resources. These distributed Agile teams often have unique challenges that the Agile process doesn't address.
The biggest challenge managers face with a distributed Agile team is a breakdown in communication. Typically a distributed team is composed of an onshore Product/Business Owner and development staff partially or fully offshore. From a U.S. perspective, the time zone difference can vary from a few hours in Latin America to 12 hours in parts of India. (The time zones I discuss here are from an Eastern Standard Time, EST, perspective.) This time zone difference coupled with the lack of co-location is conducive to a breakdown in communication, and dealing with this challenge needs to be of primary focus. In this article, I discuss optimizing communication when managing a distributed Agile team. Although many forms of Agile exist, I focus here on principles from a SCRUM management and an XP engineering perspective and presupposes a basic understanding of both.