“A fundamental aspect of agile is really quick feedback,” Kenefick
says. “If you’ve got people in di;erent time zones, you won’t have
those conversations as often as you need to. I’ll write some code
today, but then I won’t get feedback on it for 24 hours.”
That’s one reason why the agile methodology works so well
when teams are all in the same place, he adds. “It is very hard to
colocate teams, but it’s the first thing I’d put on my list of e;ec-
tive agile practices.”
If outsourcing agile development makes a challenging job
even more so, is it a better strategy to keep all agile development
in-house? For a growing number of companies, the answer seems
to be yes. “We’re seeing a trend toward companies that have out-
sourced in the past choosing to invest in their own people’s skills
and capabilities instead,” Adamopoulos says. “Smart companies
are figuring out that the cost savings from outsourcing aren’t that
significant. For instance, one insurance company we work with
is bringing more of its development for key projects back in-house
so as to have better employee retention and less risk. Their view
— which has been that of a number of our clients here and in
Europe — is that traditional outsourcers aren’t helping them get
products to market fast enough or well enough. The change rate
is slower on the outsourcer side, so to o;set that, they’re building
up the capabilities of their own people.”
That’s the decision Medidata made last year when the company
decided to expand one of its software o;erings and once again
took a serious look at outsourcing agile development. “We decided
to hire and increase the size of our internal development team
instead,” Newbigging says. “We feel quite strongly that we’re better
o; having our own developers building the software, and also being
responsible for maintaining it, responding quickly to any issues.
They are able to understand the software because they built it in the
first place, and that’s harder to achieve if the original development
was done elsewhere. You don’t have that same depth of knowledge.”
Continued from page 20
Outsource for the Right Reasons
While keeping all agile development in-house may top the wish list
of many I T leaders, it’s not a realistic plan for every company or every
situation. With looming technology skills shortages and pressure on
IT budgets, some agile software projects will have to be outsourced.
So how do you decide if it’s right to outsource an agile project?
Begin by asking yourself what you hope to gain from working
with an outsourcer. “The ideal reason is so as to give immediate
response to a business need,” says Max Rayner, executive-in-resi-
dence at consulting firm Hudson Crossing. “Can you find ways to
also have it lower cost? Yes — but something important enough
to be done in an agile way is likely to be worthwhile, whether
you’re paying $1,500 a day or $1,000 a day or $750 a day. By going
to some of the lowest-cost countries, you can get a very compe-
tent programmer for $25,000 a year, including benefits — but
that’s not necessarily going to help your project succeed.”
Before joining Hudson Crossing, Rayner was CTO at Travel-
Zoo and oversaw the creation of the travel search site Fly.com,
for which he used an outsourcing company based in Lisbon,
Portugal. “That was a 100% agile project using scrum,” he says.
(In scrum, small teams work on a specified portion of the require-
ments for a limited amount of time and hold daily meetings to assess
progress and address any questions or problems.) “I was in Califor-
nia, so we had hardly any overlap in our work days, but it worked
Team
Augmentation
A different approach to outsourcing agile
WHEN SCIQUEST, which provides soft- ware-as-a-service supply chain manage- ment 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 stu; down that we send to them.”
To further aid collaboration, one of the outsourcer’s de-
velopers 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 sta;, but he’s also our account man-
ager. 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 start-
ing 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.”
» Daryl Broddle:
SciQuest’s agile
outsourcer is a
true partner.
