Agile development has its own set of problems and challenges, but when combined with outsourcing, many of these...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
are amplified and new problems are encountered. However, there is a set of best practices that will ensure that these problems are addressed appropriately.
Up front risk reduction with hybrid Agile models
Outsourcing introduces an element of additional risk for the client and the service provider when it comes to software development. Not having very detailed requirements documents in the beginning may force a service provider to bid for a project only on a time and materials basis. The client may not like an open-ended contract where the schedule for the completion of the project is not known. This risk can be managed with a hybrid Agile model where you do reasonably detailed requirements gathering, not as detailed as a regular waterfall model would have required, but somewhat shorter in duration and producing a short and precise requirements set. Enough companies and their outsourcing service providers have been burnt with pure Agile methods that this is becoming common and a best practice. Unlike an internal development team practicing Agile, an outsourcing service provider has contractual obligations with a client and these need to be spelled out as clearly as possible up front to prevent legal problems down the road.
Organizing work and people for outsourcing along requirement areas or features
Outsourcing by itself exacerbates problems in communication, the driving force in Agile methods, because of time zone differences, language differences, etc. Agile methods work best when all stakeholders can be face to face, but in outsourcing this cannot be the case most of the time. So one of the best practices here could be organizing the work along requirement areas or feature sets so that the outsourcing team is responsible for some standalone requirement area or a specific feature set. This minimizes the problems in communication since a majority of the execution team is located physically together. It also makes it easy for product owners to travel and have face to face meetings with the rest of the Agile team all in one place.
Modifying Agile methods to ease clients into them
Outsourcing service providers encounter clients that may not be familiar or comfortable with Agile methods in outsourcing situations. This happens more often than we think. Many large and medium sized companies that have been using waterfall methodologies are on a concerted effort to try and adopt Agile methods. So service providers may encounter clients’ employees who may not be fully familiar and well-versed in Agile methods as yet. There may be a need to adopt hybrid models at first and slowly ease the client into doing things the Agile way. Many clients have been turned off by Agile methods when they are implemented too quickly without allowing a cultural shift and adjustment to happen with the client and their employees.
Managing runaway scope and requirements with change orders
Agile methods can be open-ended in an outsourcing situation where requirements were not very clearly defined up front. Specifying everything up front to the nth level of detail defeats the whole purpose and philosophy of Agile methods. Including a change order process in each iteration is the best way to unearth and implement requirements. Change orders are nothing new in the outsourcing arena and the same need to be applied judiciously as the solution that can break this logjam. Service providers do precise, short and rough-cut requirements documents at the beginning of the project without a full-blown, extended requirements phase. Change orders provide a fair way for clients and service providers to place limits on changes necessitated by Agile iterations. Runaway scope is a constant problem with Agile and outsourcing. Change order processes provide an equitable solution to resolve this.
Interleaved quality assurance
Traditional quality assurance methods with waterfall or other traditional models assumed that there is a distinct QA phase at the end of coding and development, and the software is handed over to the QA team at the end. This is especially true if QA alone is outsourced. This will not work with Agile and especially with outsourcing situations. QA teams needs to be involved with the project right from the beginning and whenever there is a new test build on the staging machine, the client and QA teams do their testing and create defect tickets in parallel. In addition to radically multiplying the number of test cycles the product or the project goes through, increasing quality by an order of magnitude, this single change in how QA groups operate brings in speedier tracking of defects and resolving them rather than waiting or the end of the development cycle and doing their work once. In practice many clients are surprised at the dramatically increased number of defects unearthed and addressed simply due to the additional test cycles the software goes through.
Agile software development works well in small well-contained teams located physically together. However, introducing an element of outsourcing brings in a host of problems with location, time zone differences, and language differences. Contractual obligations that a service provider faces with a client introduces yet another dimension to be managed well for success of the project. However, there are a number of best practices that address each of these problems with a workaround or a solution. These best practices when followed diligently increase the likelihood that the entire effort is successful!
About the author: Nari Kannan is currently the Chief Delivery Officer of V-Soft Consulting, Inc., a Louisville, Kentucky-based software consulting firm. Nari has 20 years of experience in information technology and started out as a senior software engineer at Digital Equipment Corp. He has since served variously as vice president of engineering or CTO of six Silicon Valley startup companies, working in the areas of business process improvement, IT consulting, automotive claims processing, human resources and logistics applications.He can be reached at firstname.lastname@example.org.