Software Development
In "Outsourcing Examined" (The Agile Edge, April 2003), I argued that Western developers need to become agile to survive the onslaught of Indian outsourcing companies. I claimed that a team of agilists is more productive than a team of offshore outsourcers following a traditional, Capability Maturity Model Integration (CMMI)-based approach. Even though the agile developer's fully loaded cost might be $100 an hour compared to the outsourcer's $25, the agile practitioner would produce better software faster using far fewer personnel. This claim seems to hold in practice, but what if the outsourcers take an agile approach? Suddenly, the tables turn.
In February, during a trip to India, I delivered a series of management seminars overviewing agile software development. Many participants worked for outsourcing firms and clearly understood the need to produce high-quality software in a cost-effective manner. I spoke with many people about ways to overcome the challenges faced by outsourcers and their clients when adopting agile techniques.
Facing the Challenges
Outsourcing's primary challenge lies in the distance, time and cultural differences that erect barriers to communication. Because of these barriers, the development team is more likely to misunder-stand requirements, and project stakeholders have fewer opportunities to discover that those requirements have been misunderstood.
To counteract these problems and limit the project's financial risk, clients usually insist on a serial, fixed-bid process. Unfortunately, because the fixed bid is typically based on a detailed requirements document initially developed by the client, this approach dramatically increases project risk and virtually guarantees wastage, for several reasons.
First, if you insist that your stakeholders define their requirements up front, they tend to identify fictional needs. "I don't know if I'll actually need this feature, but if I don't ask for it now, I may never get it" is all too common during the requirements phase on a serial project. Second, due to changes in your work environment, your needs evolve throughout the project lifecycle, rendering some original requirements obsolete. Third, people aren't adept at defining what they need, but they are good at defining what they don't want once they see it. Fourth, to protect themselves from "scope creep" and ensure the client's financial responsibility for any changes, outsourcers may insist on an arduous change-control process. It's often too expensive for the client to request changes—exactly the goal of the outsourcer's change prevention process—so they don't do so.
Communicate and Collaborate
To overcome these communication barriers and succeed at outsourcing, you need to adopt more effective ways to communicate, write concise instead of detailed documentation, nurture a close client/outsourcer relationship, take an evolutionary approach to requirements, and measure progress through the regular delivery of working software.
The first step toward agility is to improve the ways that developers and project stakeholders interact. Communication approaches vary in effectiveness: If face-to-face communication isn't possible, hold a videoconference. If that isn't feasible, pick up the phone.
Second, rethink your approach to documentation. Your fundamental goal is to understand requirements; whether or not they're thorough is a completely orthogonal issue. You have no guarantee that developers will read, let alone understand, a requirements document. In India, an outsourcing employee told me that he distills 100-page client requirements to several-page documents from which the developers then work. His company found that developers were far more effective working from these concise documents than from the overly detailed specifications provided by their clients—the client's effort to get the requirements specification "right" was mainly a waste of time.
If you reduce documentation, you must increase the interaction between your project stakeholders and the developers. I advise outsourcer representatives to colocate with the businesspeople at the client site. Minimally, business and test analysts should act as interfaces between the two groups; better still, some developers should also be on site. You'll need to fly people back and forth between the two sites—although this increases your costs, it dramatically reduces your risk of communication failures. Ideally, some client staff should work at the outsourcer and some outsourcing staff at the client sites, rotated on a regular basis to minimize the impact on their family lives. On a long project, all of the outsourcing staff should rotate at least once to enhance their understanding of the client's environment; this builds bonds among the people involved, reducing the impact of cultural differences.
Several of the outsourcers at my seminars have started on this path. Now, outsourcers commonly use analysts who work with onshore clients, facilitating communication with the developers in India. A few people told me that they had suggested rotating developers to the client site, but their clients tended to balk at the additional costs. I guess we're still taking baby steps toward success.
It's time to abandon the idea that fixed bids reduce risk. Clients have far more control over a project with a variable, gated approach to funding in which working software is delivered on a regular basis, perhaps once a month; then, at that point, you determine whether to continue the effort. In this way, the client controls exactly how much is spent. Better still, he can change requirements as the project progresses, because the outsourcers need merely to build upon the software that they've already delivered. Would you rather take a fixed-bid approach that may offer a firm estimate up front, but results in significant wastage, or a gated funding approach that doesn't guarantee how much you'll spend, but enables you to spend wisely?
Everyone I talked to in India hesitated at the idea of gated project financing. Although they considered this a better approach for both the onshore client and the outsourcer, they unfortunately believed that few clients would be willing to do it—the client's need for an up-front estimate to supposedly limit costs was far greater than their need to invest in IT projects intelligently. I surmised that many of the onshore clients hadn't thought through the implications of what they were requesting.
Agility Behind the Scenes
Outsourcers are becoming more agile in the way that they're developing software. Common agile techniques such as test-driven development (TDD), code refactoring and database refactoring are quickly being adopted, as are agile model-driven development (AMDD) concepts.
In addition, outsourcers are adopting more collaborative development techniques. They realize that software development is a lot like swimming—dangerous to do alone.
Yes, outsourcing erects serious barriers to communication—but these can easily be overcome with common agile techniques.
Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor, and trainer with AmbySoft Inc. He has authored several books and is a regular speaker at software conferences worldwide.
