‘Why Agile?’ and Other Questions Before Outsourcing an Agile Project

1. Why do you want to do the software project in Agile mode?

Potential reasons include:

(A) You are already engaged in IT outsourcing and have a good working relationship with the outsourced vendor. You have successfully used Agile internally and want to extend it to outsourced projects.

(B) You want to outsource a new project because you do not have internal bandwidth to work on the requirements for it or the actual development. You expect that outsourcing will help you overcome the bandwidth limitation and Agile will help you to evolve the requirements through multiple iterations.

If you have chosen (A) you then have a good chance of success, since you have the trust and good communication that are critical to Agile. If you chose (C) you may pull it off but may need to reduce your expectations of cost savings, factoring in the time, effort and energy required to build a relationship with an outsourcer.

But if you have chosen (B) your project will be doomed. Agile is communications-intensive even when done internally, and bringing in outsiders just increases the effort. If you can’t devote time to understand your requirements and create the stories (required functions), answer questions. and meticulously review deliverables your project will be doomed.

2. Do you want to outsource just this project or are you looking for an ongoing partner?

This question is relevant only if you do not already have an outsourcing partner, but is important because Agile without trust does not work.

Trust is established between individuals, not organizations, and there is no substitute for key people from both the customer and outsourcer working together at the start of the project. One month would be ideal, but even if you need to cut costs you should still plan on at least one week.

In addition, Agile requires investments in smooth and effective communication, whether that is a dedicated communication link, video conferencing facility, or joint development tools. Doing it for just one project may not give you sufficient return on the investment.

3. What type of contract model should you look at?

There are three alternatives – either one or a combination can work for you.

(A) In a Time & Material (T&M) contract you agree on the rate for different people will different levels of experience and expertise and pay the vendor based on how much time they spend on your project. Though this is the simplest mechanism all the risks are with you and the vendor has no incentive to work more efficiently.

(B) In a Fixed Price contract you define the scope of the project in sufficient detail and agree to pay a fixed price. This runs counter to the basic philosophy of agile where you actively encourage requirements to evolve and change. Therefore, this requires a mechanism to compensate the vendor for changed requirements and rework, which you may do in a T&M basis. However, you need to keep in mind that what is a change and what is within scope can become very controversial.

(C) The third model can be based on some objective measure of the amount of work done, such as Story Point or Function Point. Each has its own advantages and disadvantages. I prefer MK-II Function Point which provides a good basis for calculating incremental effort. However, it does not cover effort required for rework, refactoring and the impact of technological change.

While there is no one best model, a good approach is to sign a Master Services Agreement (MSA) which specifies the overall terms and conditions including rates, but does not get into the specifics of a project. The scope of work can be outlined through a Statement of Work (SOW) that can include high-level product backlog.

4. What are the payment terms?

Since Agile is iterative with the continuous delivery of “potentially shippable products,” you need to pay either at the end of each iteration or at pre-agreed intervals. If you pay at the end of each iteration you must have a process for handling bugs or other defects. You can:

(A) Accept that some defects are inevitable and will be fixed in the next iteration and make the payment. This is not a good idea.

(B) Set a threshold of acceptable defects and create a separate sprint to correct them, accepting the iteration only after all the defects are closed. This may upset your sprint planning.

(C) Require the vendor to correct the defects in addition to the work required in the sprint, releasing payment only after all the defects are closed. This puts additional load on the team but forces them to deliver a better product.

Remember also the Agile philosophy to fail early rather than fail late. Consider a contract clause allowing you to terminate the project midway if you realize you are not going to get the business benefit envisaged.

5. Does the vendor understand your definition of “done”?

Another Agile principle is that “Working software is the primary measure of progress.” But an enterprise has wider needs, so when defining “done” also consider:

• How you are going to test the delivery?

• How much documentation is required?

• Is there any architectural or design standard that need to be followed?

• Do you have a coding standard and code review guideline?

• Do you need to have usability testing done?

• What are the integration needs and how will you test it?

• How are you going to measure performance under load?

• Who is responsible for fixing issues while deploying in preproduction and production?

Udayan Banerjee is an IT industry veteran with more than 30 years experience and interests in cloud computing, SOA, Web2.0, RIA, knowledge management, code comprehension & transformation, Agile methodologies, mobile computing and model-driven software engineering.