5 Questions to ask before you take up an Agile Contract
You are a software service provider. You develop software for you clients. Majority of your clients are from a different city or even a different country. You are in a discussion with your client where you are exploring the option of adopting Agile Development Methodology for your next project.
Does the above paragraph describe you? Are you concerned about how the whole thing will work out?
If the above paragraph describes you, then I can assure you that you are not in minority. Many of us have been in a similar situation.
The biggest challenge of adopting agile for an outsourced project is that there aren’t any clearly defined best practices available which you can adopt. The whole field is still evolving and the best practices are yet to emerge.
So, what should you do to increase the chance of success?
Obviously, you will have to find the answer yourself. To find the right answer, you need to ask the right question!
Let me set you thinking on what questions you need to ask. Here are 5 of them:
1. Is your understanding of Agile same as your clients understanding of Agile?
Please remember, there is no common accepted definition for agile. Yes, there is the Agile Manifesto but that can hardly be called a definition. It is more of a vision of how to develop software which delivers business values. The manifesto indicates that the best way to develop software is to create a “co-located” “cross-functional” team of “competent” individuals and allow them to “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 collocated. The prescribed method of software development becomes infeasible when the size of the problem grows beyond a point. Yes, one small team can be very productive but there are many real life problems where it becomes impossible for a single team to handle. Similarly, when experts across multiple locations need to collaborate, co-location is not really an option. As a result, where outsourcing is involved, the agile process will deviate from what is envisaged in the manifesto.
There isn’t any common understanding of what the deviation should be. So you need to have your own interpretation of the “agile methodology” that you want to follow. What you need to keep in mind is that your interpretation may be different from what the client expects. So, the most important task should be to identify how much is this difference in interpretation?
If the difference is small then you would be lucky because you would have crossed the biggest hurdle. However, if the difference is significant then you need to decide if you want to follow your client in agile adoption or do you want to act as the thought leader and convince the client about your interpretation?
If you have a mismatch of the interpretation it will definitely result in mismatch of expectation and erosion of trust.
2. On what basis are you going to get paid?
Though one of the 4 principles of 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 going to be a mechanism or a formula to derive how much you are going to get paid for the service that you are rendering.
If client is willing to pay based on the hours logged by the team members and ready to take the responsibility of the output of the team then you don’t have to worry.
The current trend is to link the payment to output. There is no standard method of achieving this and you need to work it out with each client separately. There are two alternate mechanisms to achieve this.
In the first one you agree on a scope of work and a price for the same. The scope can be defined for an “iteration” or for a “release”. You also agree on a mechanism for arriving at the deviation from the agreed scope and method of calculating how much you will be compensated 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. However, whatever may the mechanism be, it should appear to be fair for both parties.
You need to work for a win-win without which you will not be able to build the trust required for the success of the agile project.
3. How will the iterations be accepted? How will the project close?
In most cases, your payment will be linked to a milestone. It may be on a completion of “iteration” or the delivery and acceptance of release. Will the client pay you as soon as you make the delivery or will the pay only after they have verified the delivery and found it acceptable. What happens if there are bugs? Would you have to fix them before you are paid? Will that be a separate delivery or will they be fixed in the next iteration. What happens if there is a delay in reviewing the delivery?
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.
It would a big mistake not to address the issue of “method of acceptance” before starting the engagement.
4. Will your communication infrastructure measure up to client expectation?
Insisting on co-location while outsourcing a project may not make sense. In most cases it will defeat the purpose of outsourcing. Therefore once you give up on one of the original agile premise of cross-functional collocated team you will 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 which will 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. You also need to figure out if all your team members are comfortable and confident about discussing road blocks with the client representative.
For a distributed team it is difficult to achieve continuous interaction without the support suitable technology and infrastructure support.
5. How transparent do you have to be about your team composition and organization?
Is self-organizing team a necessary precondition for executing an agile project? The view among the experts range from (A) “yes, it is a must” to (B) “it is a good thing to have but not mandatory”.
If your clients fall into the second category and he leaves the problem of team organization to you then you don’t have to worry too much about team self-organization. If you are able to create a self-organizing team you will be better off and be more productive. Without that also you will still survive.
However, if the client insists that the team has to organize itself, the scrum master will only play the role of facilitator and you are not going to have a project manager then you need to clearly understand the implication. If your whole organization is only using agile methodology then you may not have a problem. But if like most of software service provider you use a mix of many different development life-cycles – this distinction becomes very important.
To support self-organization you will need mature team members and experienced scrum master.
There is enough evidence that agile works better than traditional methods … even in outsourcing situation.
Therefore, agile is going to get adopted – question is “are you prepared”?
[A version of this article is also published in Global Delivery Report]