Offshore development may save an organization money, but it can also create software quality challenges. In addition,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
it's difficult to use more agile development methodologies when you have geographically dispersed teams. But there are ways to mitigate both issues, experts say.
One issue with offshore development can be increased defect rates, according to Michael Mah, a managing partner at QSM Associates Inc. (Quantitative Software Management) in Pittsfield, Mass., and a senior consultant with Cutter Consortium.
"We're finding from our research that projects that are multishored pose greater challenges in optimizing that communication between geographically disbursed teams," Mah said. "Projects that are increasingly being driven outside North America, or outside Europe, to a lower-cost labor market, is resulting in project defects actually rising."
He added, "That's not to say that in the end the production code might not meet a high level of quality. It could if people take the time to work out the additional defects through testing, but that flies in the face of tight deadlines."
The practice of specifying a lot of the requirements up front also flies in the face of agile practices and contributes to the quality challenge, said Joe Niski, an analyst at Burton Group, based in Midvale, Utah.
"The recommendations you typically see for companies considering [offshoring] are that you need to be even better at specifying requirements upfront," he said. "At the same time, we've got experience saying that trying to specify so much upfront doesn't work."
Niski continued, "Big [offshore] houses have proprietary methodologies that are still very 'waterfall-ish.' No matter how much you try to specify software upfront, it's hard for customers to have a real idea of what they need until they can see something onscreen and interact with it."
Distributed teams also a factor
Even if an organization doesn't utilize offshore development houses, distributed teams are just a fact of life in our global economy. And distributed development projects face many of the same challenges as offshoring.
"Even though you have email, even though you have conference calling, there still remains an inherent part of design where anything that's going to be less than when you have people in one room [is less than ideal], and yet the realities of today's workplace is you don't always have the luxury of having people in a room," Mah said.
"Today you've got two very actively discussed philosophies of developing software," Mah added. "One is using lower-cost offshore labor, and the other is developing it with an agile team. At its very essence, agile development or XP isn't something that tends to be outsourced. It doesn't lend itself to be outsourced very well, but some people will want to try that."
In fact, Gary F. DeGregorio, vice president of global IT consultancy ThoughtWorks, said his organization, which has offices in the U.S., the U.K., India and China, does just that.
"We use the same practices with our distributed teams as our co-located teams," he said. "Our development approach is agile best practices. We're ensuring quality by taking lean manufacturing principles and applying that to software development."
To make agile practices work for distributed or offshore teams, DeGregorio offers these tips that ThoughtWorks follows:
- Focus on short iterations and quick feedback cycles.
- Do upfront testing, i.e. test-driven development and unit testing.
- Incorporate a high degree of automation, particularly around regression testing and continuous integration. Use lightweight regression testing tools.
- Keep up with development iterations and regression testing.
- Overcompensate for communication and collaboration.
DeGregorio's last point is perhaps the most critical, he said. "The burden is on project managers, iteration managers and team leads. There is a high degree of communication and coordination involved with distributed teams. There are late night/early morning handoffs between teams, a lot of conference calls, one-on-one phone calls, the use of [instant messenger], and a strict discipline toward keeping collaboration tools like wikis up to date."
DeGregorio also recommends rotating team members so they can meet the clients and be more involved with planning. "Making sure rotations of offshore [workers] coming onshore and onshore [workers] going offshore during the course of a project really help[s] in terms of transferring the body of knowledge and interpersonal relationships."
For organizations that engage firms such as ThoughtWorks for distributed or offshore development projects, the biggest concern is not so much quality but visibility, DeGregorio said. "How do they know work is being done? How will they get status? How will they interact with the team? Maybe they're not so much focused on the cleanness of code, but will the application do what they envision? Will they be able to document business needs if the team is not co-located?"
ThoughtWorks allays those fears through communication and transparency of process, DeGregorio said. They do so by making sure the client has full access to the repository and by using online dashboards for the client to see projects' defects statistics and the status of iterations."
ThoughtWorks also brings the client into the planning process and makes sure there are meetings throughout the iterations. "The more we can engage clients to participate and assist in the review of iterations, the prioritization of requirements, and understand the risk of mitigation, the more comfortable they'll be," DeGregorio said.