Document Actions
on offshoring
My friend Scott Sehlhorst offers a detailed view of what it takes to make outsourcing work. He explains that there are essentially four different models for managing a software development project with respect to onshore and offshore roles. Read Making Offshore Development Work.
I find that there's a trade-off that isn't appreciated or understood by the advocates of offshoring. The trade-off is between domain knowledge and required detail.
You can be brief and agile with a group that understands the product and the domain; you must be extremely specific when dealing with people who do not. And with this required detail comes more time in meetings and more time writing artifacts--and less time building product.
Whether onshore or off, a product team needs to understand the personas and their problems. If you're dealing with people who "just want to code," someone on your team will have to detail everything exactly as you want it delivered.
Thanks and You're Right
You're exactly right about domain context and artifacts. This particular model (sending development, but not design, offshore) absolutely suffers from the latency in the communication between design and implementation.
As you say, this means more "packaged communication". At least if you want to minimize the chatter across this lagging communication channel. Alistair Cockburn, when Crystal was about to come out, mentioned the idea of video taping whiteboard sessions as a means of 'no overhead' documentation. If you combine this with a teleconference as a daily standup, you can both communicate effectively, and document the communication.
This, combined with code and test reviews can be an effective way to reduce the chattiness needed between design and implementation.
In my next outsourcing article, I'll write about the communication dynamics when design is also outsourced.
Thanks again!