To get the best results from agile outsourcing, both customer and developer must be clear on everything from their understanding of agile to how iterations will be reviewed and paid for. That’s the advice from Udayan Banerjee, a 30-year industry veteran, frequent contributor to Global Delivery Report and technology blogger. He wrote the following piece for software development firms, but as you’ll see his advice applies equally to customers.
1. Do customer and provider have a common understanding of “agile?”
There is no commonly accepted definition for agile. The Agile Manifesto is more of a vision that includes the creation of a “co-located” “cross-functional” team of “competent” individuals who “self-organize” and deliver “working” software “regularly” which delivers “business-value.”
In today’s complex globalized world it may be impossible to keep the software team small and co-located, especially when a problem grows beyond the capabilities of a small team, however productive it is. Similarly, when experts across multiple locations need to collaborate, co-location is not an option. As a result, where outsourcing is involved, the agile process will deviate from what is envisaged in the manifesto.
Since there is no common understanding of what that deviation should be, you’ll need your own interpretation of the agile methodology that may be different from what the client expects. If the difference is small then you are lucky and have crossed the biggest hurdle. If the difference is significant the developer needs to decide if they want to follow the client’s lead, or act as the thought leader and convince the client their interpretation of agile is best.
Lesson: A mismatch of the interpretation will result in a mismatch of expectations and an erosion of trust.
2. How will payments be made?
Though one of the four principles of the Agile Manifesto is “Customer Collaboration” over “Contract Negotiation,” in an outsourcing situation it is impossible to avoid contract negotiation. The key element in your contract is the payment mechanism or formula.
If the client is willing to pay based on the hours logged by the team members and ready to take responsibility of the output of the team you don’t have to worry. However, the current trend is to link the payment to output. Since there is no standard method of achieving this you will need to work it out with each client separately. There are two alternate mechanisms to achieve this.
The first is to agree on a scope of work and price for that work. The scope can be defined for an “iteration” or for a “release.” You also agree on a mechanism for arriving on any deviation from the agreed scope and for calculating payment for the extra work. Alternately, you can come up with a formula to calculate the size of the work delivered and a method of calculating the price for that. Whatever the mechanism may be, it should appear fair for both parties.
Lesson: Work for a “win-win” agreement, without which you will not be able to build the trust required for success.
3. How will iterations be accepted? How will the project close?
In most cases, the developer’s payment will be linked to a milestone, such as completion of an iteration or the delivery and acceptance of release. Will the client pay you as soon as you make the delivery or only after they have verified the delivery and found it acceptable? Do you have to fix any bugs before receiving payment? Will bug fixes be a separate delivery or be fixed in the next iteration? What happens if there is a delay in reviewing the delivery?
The best way to overcome this problem is to deliver good quality software and adjust your iteration cycle-time to match the client’s ability to review it, give feedback and finally accept the delivery. Also, it is a good idea to have a clear understanding on how the project is going to be brought to a closure. In the over eagerness to start the work, the method of acceptance may not be fully resolved.
Lesson: It is a big mistake not to address the issue of “method of acceptance” before starting the engagement.
4. Will your communication infrastructure measure up to the client’s expectation?
Insisting on co-location while outsourcing a project may not make sense and in most cases will defeat the purpose of outsourcing. Once you give up on one of the original agile premises of a cross-functional, collocated team you face another set of challenges. Irrespective of what agile may say, tools processes and technology will come to your aid to ease the burden of multiple locations.
You need to put in place suitable infrastructure that support direct, interaction between all members of your team and the product owner and other relevant people in the client organization without any delay. You also need to have in place suitable tools and process in place for sharing information like story, backlog, open issues, bugs etc. Additionally, you need to figure out if all of your team members are comfortable and confident about discussing road blocks with the client representative.
Lesson: For a distributed team it is difficult to achieve continuous interaction without the suitable technology and infrastructure support.
5. Must you use a self-organizing team?
Some experts say self-organizing agile teams are a must; others call them good but not mandatory.
If your client falls into the latter category and leaves the problem of team organization to you then you don’t have to worry too much about which path to take. A self-organizing team will be more productive, but without it you will survive.
But if the client insists the team has to organize itself, the scrum master will only play the role of facilitator and you will lack a project manager. If your whole organization uses only agile, you may not have a problem. But if like most providers you use a mix of development methods, the distinction becomes very important.
Lesson: To support self-organization you will need mature team members and an experienced scrum master.