Perhaps most important is a willingness to face up to the profound changes that a move to agile requires. "There was one large logistics company in Europe with an outsourcing agreement with a very well-established systems integrator," Adamopoulos recalls. "The systems integrator's model wasn't helping the logistics company. It wasn't getting new features fast enough and was losing market share. Every time IT executives had a conversation with the outsourcer about agile, the outsourcer would make some minor change, but then things would go back to status quo."

The logistics company hired Emergn to train both its own team members and its contacts at the outsourcer in using the agile methodology. Once they were trained to employ agile properly, they were able to shorten the average release time for a new feature from 300 days to 47 days, Adamopoulos says. "The logistics company reclaimed about 21 million euros in revenue that year because they were able to move feature releases up 10 months. In the past year, they've also regained a fair amount of the market share they'd lost."

He was especially impressed with the outsourcer's ability to completely change the way its developers worked. "That was a huge win, and it's gotten companywide recognition at the outsourcer," he says. "They're beginning to use the agile methodology within their own organization as well. They recognized it was something they needed in order to remain competitive."

Large or small, an outsourcer willing to make changes like these is probably a good bet if you are facing the challenging prospect of outsourcing agile development.

Can we talk?

When people on the East Coast arrive at their offices at 9 a.m., it's already 7:30 p.m. in Bangalore. That might not be a big problem in the old-fashioned world of waterfall software development, but if you're using agile, which requires constant communication among developers, testers and the business users of the software, having team members in different time zones poses a serious challenge. What can you do? Here are some tactics that have proved effective for successful outsourced agile projects:

1. Write detailed requirements. "When we need to exchange information about detailed requirements, the time difference is a challenge," notes Rene Rosendahl, senior manager in the project management office at Kelley Blue Book. "We're mitigating that by providing more detailed written information than would be needed if it weren't offshore. The goal is to minimize the questions that come back to us."

2. Use collaboration technology. Kelley Blue Book uses a tool called VersionOne to manage agile projects and keep the lines of communication open within its agile teams. And that's not all. "We are heavy users of instant messaging and email," Rosendahl says. "So if someone's gone home for the evening and offshore team members need information from that person, they might get it via email or IM."

3. Ask offshore workers to match your time zone. Many developers in other parts of the world approach agile development for U.S. companies by working hours that, to them, are odd. "Most of our team based near New Delhi are operating on Eastern time. That helps a lot," says Shane Aubel, CIO of the outsourcing company Tarika Technologies. The Indian workers are at their jobs from around 11 a.m. their time to 7 or 8 p.m., he adds.

It helps to not keep anyone on the late shift for too long, notes Kevin Quick, North America testing lead for Capgemini. "It's a rotational thing, so our people can manage their lives well," he says. "We learned the hard way that if we leave people on the late shift for too long, we tend to lose them."

4. Keep some team members onshore. "My biggest recommendation is to make sure that the designers, architects and engineers are located onshore," Aubel says. "We do a lot of the architecture, design and requirements, and then the specifications we send to the team are pretty well defined. It's just a matter of coding. The challenge arises when you try to start offshoring design and architecture."

But some industry experts are skeptical about this sort of approach for a truly agile methodology. "If you're doing waterfall development, it's OK to have a Java person who only knows J2EE," says Max Rayner, executive-in-residence at Hudson Crossing. "In agile, you want developers who think like business people. It's not enough that they can program. They have to be engaged and challenge the demands, thinking of the outcome rather than the process. So a lot of the outsourcing companies that are coder mills have a problem because they don't have talent that is able to engage with core business matters, just on how well their code is written."

5. Buy lots of plane tickets. Videoconferencing, instant messaging, document-sharing and remote scrum meetings all help, but in the end, nothing compares to meeting face to face. So IT leaders who've successfully managed offshore agile projects recommend frequent visits -- in both directions. "You may have parts of your onshore team going offshore to meet the offshore scrum team in person and introduce them to your technology," Rosendahl advises. "And you might also plan for offshore resources to come onshore to keep the exchange going and continue building these relationships. It's not cheap, and it takes effort and time, but it's well worth it."

Outsourcers as team members

When SciQuest, which provides software-as-a-service supply chain management tools, decided to switch to an agile software development model about five years ago, the company already had a well-established relationship with an outsourcer in India. "A big chunk of our work was being outsourced," says Daryl Broddle, vice president of technology. The outsourcing company was a small, entrepreneurial firm that was willing to change its practices to accommodate the new methodology.

So SciQuest began creating teams, as in a classic agile setup. "The entrepreneurial partner augments our teams," Broddle says. "The teams focus on a strategy, and the developers at the outsourcer participate in our daily standup every two or three days. We've integrated them into our process. We don't write a bunch of stuff down that we send to them."

SciQuest is based in North Carolina, and the two companies deal with the time difference by adjusting their work schedules, something that Broddle says is very manageable. "They come in at 9 or 10 a.m. and work till 6 or 7 p.m.," he says. "We wind up with three to five hours of overlap. And if we need to have a meeting where we have to have a long discussion, then we'll come in at 7 a.m."

To further aid collaboration, one of the outsourcer's developers is on-site full time at SciQuest. "He's one of the four people on one of our four-person teams," Broddle says. "I treat him as one of my staff, but he's also our account manager. For instance, if one of the developers in India is not working out well, he handles it."

This scenario has been working well for more than five years, Broddle notes. "They were pretty small and just starting out when we first started partnering with them," he says. "They've grown along with us, and they are now about four or five times as big as they were when we began."

Working with the outsourcer lets SciQuest meet its goal of getting new features to customers faster. "We have three major releases a year, but in between we use focus groups," Broddle says. "We show them new functionality and get their input long before we put a new feature into the production environment. With the outsourcer augmenting our teams, we can get something done and ready to implement in front of our focus groups within a two-week sprint. We're not showing them screenshots -- it's real code."