Trigent Insights newsletter - 7 techniques to successful offshoring and outsourcing product development

In the last few weeks, we discussed 4 Techniques to make Software Offshoring a quick, painless and value-added proposition. This week, we're continuing our 5-part series with Techniques 5 & 6.

Technique 5: Test continuously
A home truth, but neglected when the pressure to release the product with features is high. Ask yourself - what is the average time taken in your product between error introduction and error detection? This is a powerful metric of the efficiency and productivity of the delivery team. But the sad truth is that you get the stock reply – "I don″t know!".

Any experienced software professional will recognize that the later it takes to detect a problem, the longer it takes to fix it. The developer may have forgotten the context, developers could have changed, and there could be several other reasons, but the challenge is early detection. There is no magic solution other than to test continuously.

Beta testing by customers, testing by domain experts, and other key stakeholders are effective means that go a long way in early detection and quality delivery.

Make the product available on a test server for beta testers, domain experts and supportive customers.
If the product has an implementation team, involve them early in pre-release testing
Have frequent test and feedback sessions with developers
Measure and improve the ″time taken between bug introduction and bug detection″

Technique 6: Separate the development and support teams
This is the hardest of all techniques. One of the common pitfalls of off shoring is to have one offshore team and downloading development work, assigning bug fixes and giving urgent upgrade work to the same team. This is counter-productive.

When development work gets interrupted frequently, it will disrupt the pace of work, cause context switching and results in decreased productivity. After a few weeks of repeated assignment of bugs, and all development plans go haywire. If the work also involved maintaining a schedule plan, the overhead is huge and is unproductive effort whose cost no one would like to bear.

Clear separation of development and maintenance teams improves productivity in a big way. The developer walks into office knowing what is the content of work ahead, not with ″I don″t know what is going to get thrown at me today".

If it is not feasible to separate teams, there is one alternative. For a defined period of time, say 8 weeks, identify a ″development″ team that won″t work on bugs unless unavoidable. Once the isolation period is over, revisit the need for continuing the separation. And if no major enhancements are in the pipeline, merge the teams back. This is the ″virtual″ separation of teams and works just as well when burst of development is needed.

Separate development and support teams, at least for defined period of time.

We'll be concluding this series next week with Technique 7: Reward Innovation and a Conclusion to summarize this series. It's only a short wait away!

If you'd like to learn more about how we can help you with offshore software development, for either software products or service applications, please contact us please contact us at http://www.trigent.com.