Within the context of the larger enterprise, distributed development is the norm, not the exception. After all, if one has hundreds of developers and testers, the likelihood that they are all in co-located component teams, or that the enterprise could immediately relocate them to be so, is essentially zero. Moreover, scale alone drives distribution as we know that past about 100 ft from ones desk, the opportunity for casual conversation decreases about exponentially, so even if the enterprise is located on a rare “single campus”, they are in fact , highly distributed in agile terms.
Recently, when asked about whether or not distribution alone can be an Achilles heel to enterprise agile adoption, I answered “absolutely not” as I’ve seen it work extremely well even in the face of what some would consider extraordinarily distributed teams. For example, the BMC quality and productivity case study by QSM (see the post at https://scalingsoftwareagility.wordpress.com/2007/09/21/newly-release-quantitative-data-on-enterprise-agility-benefits-at-bmc-software/)contains the following quote:
“Especially noteworthy is the fact that BMC has found a ‘Secret Sauce’ that enables its SCRUM process to succeed in spite of teams being geographically dispersed. Other companies experience higher defects and longer schedules with split teams, but BMC does not. I’ve never seen this before. The low bug rates also result in very low defect rates post-production, which is great news for their customers who demand a high quality product.”
On the long flight home from the enterprise where I was asked that question, I found myself second guessing my own comment, as it flies in the face of so much that is considered critical, or even mandatory, for true team-level agility. And yet, as I reflect on my personal experiences, I feel comfortable in boldly stating that “of all the challenges enterprises face in adopting large-scale agile, the problem of distributed teams ranks fairly low on the list.”
And then I had to ask myself why. I suspect there a number of reasons that distribution alone is not as critical to enterprise agility as I once assumed. These include:
- The define/build/test team (See Chapter 9 of SSA), even when distributed, is still a TEAM. They have all the skills they need to deliver working software. In addition, agile teams are both empowered and challenged to address their own challenges. If they are distributed, so be it, and they must find their way to communicate to be as effective, or nearly effective, as a co-located team. In other words, it isn’t necessarily management’s problem if it is impractical or undesirable to relocate team members or change technical assignments to facilitate collocation, rather it is the TEAM’S problem, and they will solve it for themselves.
- Their mission is clear. No matter the distribution, the team’s mission is clear – to deliver working software every two weeks. The clarity of the mission focuses the team on what really matters, that is the state of the actual software, and they will necessarily do what they have to do to help assure the outcome.
- Individuals live where they live for many reasons. There must be some significant intangible motivation associated with the fact that the team members are in an environment of their own choosing, and yet they are still participating in a high-performance, though distributed, software TEAM.
- We are in the age of the virtual community, and we have all accommodated to enhanced forms of communication from skype, webex, IM, email, webcams, shuttle diplomacy and the like (see Chapter 19). While everyone understands the virtues of face to face communication – (agile manifesto principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation) – at the same time, no one derides distributed open source communities, which in some facets are paragons of agility, for the fact that team members are not collocated, and no one challenges the quality, productivity or delivery velocity of that model.
So yes, collocated is better, and there is nothing quite like the face-to-face communication of collocated an agile team, and yes, an enterprise should work to facilitate collocation wherever feasible, but no, it isn’t mandatory, and in all probability, it won’t even be the largest challenge the enterprise faces in its agile transformation.