Agile Contracts – Approach One

A lot of people responded back on the SCRUM Development Group to the discussion on Penalities and SCRUM. After having discussed this topic over the last two months, I personally feel [and thats with that big “I” again], the discussion on Penalities and Agile/ SCRUM is probably a subset of the overall domain which can be called “Agile Contracts“, which you can construct in different ways. Here is one approach which we have tried to follow. As the projects are currently on, its a bit too early to get to the efficacy of the approach. However, there are some early trends which are provided without bias below.

I call this approach “Traditional Approach“. This is in keeping with the letter as well as spirit of Agile. It assumes:

• Evolving requirements
• No upfront estimation [in hours] – ok I made this one up, its not really an Agile value, but well we like it
• Transparency and effective reporting
• Client Collaboration

The Contract is noticable because there is hardly anything there. Its a bit like the old “Times and Materials Contract” with focus on:

• Project Reporting – backlogs, burndown charts
• Communication Means
• Service Levels
• Types of services covered [designs/ HTML/ dot.Net coding/ QC]

The contract continues for a year at a fixed hourly rate. After a year, you can negotiate a higher hourly rate especially if you score consistently on service levels.

The problem really is that despite its simplicity, it is difficult to sell this to the clients, especially new clients. It can however work in the following situations:

• Existing client, fed up with fixed price approach but generally happy with service
• Existing time and materials client
• Prototypes/ proof of concept projects
• You can use your internal knowledge management system to demonstrate expertise in particular area

We have had great success with this contract [this was not the only thing but contributed significantly to relieving pressure on team and clint] with a client of ours [the client whom I explained SCRUM and posted transcript here]. The team has consistently exceeded client expectations. One of the reasons they attribute this to is “willingness to not haggle on what is covered and what not in contract” and just think of one sprint/ release at a time. The customer is very happy and we have not heard about the project for a while now and that means it is going really well. The approach has a great advantage for all parties. If you can find any disadvantage [other than difficulty in selling the approach], please do leave a comment.

Advertisement