outsourcing carries some unique risks. Forcing an offshore team to adopt and use a methodology that they are not familiar with increases the risk on the project. In addition the fundamental and operational differences between Agile and Waterfall methodologies can and do create substantial cultural change requirements that can not be adopted in a short period of time.
The reduced structure and documentation of Agile create another risk. This risk manifests itself in misunderstandings between the onshore requirements gathering team and the offshore development team as well as between the onshore requirements gathering team and the client's subject matter experts. In addition, where the application area has regulatory compliance provisions the reduced structure and documentation can create significant challenges. Often regulatory requirements mandate process documentation for audits and compliance reviews.
A significant risk that is intensified when using the Agile development approach is in the area of scope creep. Many times the user has difficult envisioning what is achievable while defining a new system. Once they begin to experience the system through the iterative development demonstrations, the "tweaking" and "wouldn't it be nice if we could" requirements expansion begins to occur. The best way to handle this issue is to push off the "tweaking" and "wouldn't it be nice if we could" to future Sprints and estimate the costs associated with them at a future time. That being said, this does tend to cause increased work for both the onshore and offshore teams and drive the overall cost of the project higher.
Perhaps the biggest area of risk is based on the degree of interactivity of software developed in early sprints and the software scheduled for development in later sprints. Highly integrated application can become very inefficient if the requirements for one area of code change through various iterations, the same programming may need to be modified several times over. Whereas, a more formal and complete program specification practices at the beginning, a single area of code could include much more if not all the needs of later programs and be developed with minimal modifications. It basically provides a bigger picture.
There is no question that integration of offshore development into an Agile program can enhance the value to customers by reducing overall costs. However, many offshore organizations have their traditional methodology engrained so deeply into their operations, it is next to impossible to get them to change. Offshore development organizations tend to focus on hard requirement established upfront, but in Agile requirements evolve over time and change. Agile and the use of offshore development that leverages the waterfall development is a tricky, risky, and sometimes very costly venture. While combining the two different techniques is a bit more risky, it is far less risky that forcing the offshore development team to rapidly adopt a new methodology for development that changes their way of operating. If the two parties are just beginning their business relationship, mutual trust has not been established and that is critical when combining Agile and tradition methods. Organizations who decide to try this hybrid development model should first fully investigate and verify the offshore company's true Agile experience and capabilities. For those who are considering the hybrid model, go into it with your eyes open. Combining the two different development styles and approach create substantial risks. You must consider those risks and weigh them against the potential time and dollar savings when making your decision. Software development is tough - this hybrid model makes it tougher.
About the Author
Kevin G. Coleman is a seasoned management consultant with nearly two decades of experience. He