Let’s start by review the positives put forward by the article:

• Methodology Fit
  The ability to make continuous process changes and improvements is a boon to two organizations trying to synch their processes for the first time.
• Bridge the Communication Gaps
  Frequent release-and-review cycles can help to bridge communication gaps.
• Perfection is Iterative
  No one gets it right the first time. Only the lucky get it right the second time. Just about everything of significant technological complexity in this day and age takes at least three attempts to get right — and when you’re talking software, thirty attempts (behind the scenes) isn’t uncommon …
• Building Expertise
  You can move your development to an organization that has built a number of similar systems in the past.
• Responsiveness to Change
  Requirements and processes change continuously … more frequent iterations allow for faster revisions of requirements and code-bases.
• Quality
  Faster feedback generally means that problems are identified – and solved – sooner in the development process.

Now we’ll look at the negatives that can result if you’re not careful:

• Methodology Fractured
  While the ability to make rapid changes can be beneficial when trying to synch processes, they can also break processes that are working well.
• Deepening the Communication Chasm
  Frequent release-and-review cycles that lead to constant improvements can give you the illusion that the communication gap is bridging when in fact the chasm underneath is deepening. The successive improvements could be due to trial-and-error and luck and not have anything to do with communication improvements. Plus, an over-focus on feature-function might cause you to ignore relationship building, which is critical if you are ever going to truly bridge the communication gap, especially with offshore development organizations in India, China, and Poland, for example.
• Running-in-Place
  The faster you respond to change, the faster the change requests start coming in. If you’re not careful, you’ll start to cycle through changes until you’re back with what you started with — after months of wasted effort.
• Lack of Robustness and Flexibility
  If you only measure quality by “how close the end-user design is to what you envisioned”, or “how many of your test cases run bug free”, you might miss the fact that the code is an unmaintainable mess of spaghetti that you’ll never be able to maintain, update, or modify again. Very Bad Code is a regular by-product of overly-aggressive agile development cycles with too many iterations. Building good code requires building a good, stable, underlying architecture that does not change. Just like you can’t use the frame of a three-story house for a 6 story office building, you can’t use an architecture for low-volume EDI message exchange for a high-volume real-time XML exchange. If you adopt a high-frequency agile development cycle and don’t take the time to get the right framework and software architecture up-front, the developers end up having to hack the code every iteration to make their changes and after five or six iterations you have a tangled mess that even a development guru won’t be able to make heads or tails of.

So while agile can be beneficial to your development outsourcing, it has to be used in moderation or the drawbacks will far outweigh the advantages.