Priya PatraDelivery Director| Capgemini India Technology Services LtdMumbai, India
Recently I was asked by a colleague on what are the necessary elements / sections of a contract for a project that is to be executed in Agile manner ?
When we sat to ponder, we found that we hardly had anything different in our contracts, which in my opinion is a gap.
Any tips , examples, suggestions what needs to go in , in such a contract ? Saving Changes...
I agree with you that we manage our agile projects exactly as we manage traditional waterfall projects. Our projects are agile only by name, specially when it comes to contracting. I am sure there are many templates available for Agile contracting, but I would suggest all the outline requirements of the whole project must be agreed in contract with a clear understanding of how changes could be flexibility brought in these requirements. The duration of sprint and the customer involvement in various stages of the project must also be clearly penned down. What re the various agile tools and techniques permissible for this contract and any assumptions or constraints laid down by customer must be made part of the contract. There could be a lot more which can be listed here but I think I must cover than in a detailed article which I will soon post on my blog. Saving Changes...
Priya PatraDelivery Director| Capgemini India Technology Services LtdMumbai, India
Thanks Suhail !
The links provided definitely will help me in formulating my next agile project contract in a more structured manner.
I am also thinking on these terms, do we need to add some specific terms and conditions, risks and assumptions for geographically distributed teams and different delivery models like transaction based and platform based models.
Any inputs in these areas will be highly appreciated.
Regards,
Priya Saving Changes...
Priya, I have gathered some material for you and copied it in one word file alongside the web references. It will answer most or all of your questions. I tried to attach that file with this message but there seems to be some problem. Kindly download it from my dropbox link below:
This is a very good discussion and information being shared on this subject. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
I disagree with just about everything Suhail said in his first response. If we are holding to agile values of embracing change, and we are willing to inspect and adapt as the project proceeds, then the idea that we HAVE to specify something like the iteration length in the contract, when obviously such a thing could be changed by the team in flight, is not only wrong but dangerous.
Similarly, agile teams adopt and drop tools and techniques as they see fit over the life of the effort. It is completely counterproductive to try to limit or sompletely specify what tools and techniques are used by the team, and it is decidely non-agile to think that you know up front every tool or technique that would suit the team dynamic during the project. Besides what possible value is there in trying to limit or control tools and techniques in the contract? Why would you want to place obstacles in the way of the team adapting, and adopting a new tool or technique, or alternatively dropping one that wasn't working?
The whole point of being agile is that you free yourself of unnecessary constraints that are imposed by traditional project managment mindsets and management styles. If I were the customer and someone walked in and told me only certain tools or techniques were "permissible" because some idiot had put them into the contract up front, I'd fire that person. I'd want to make sure bad ideas like this are kept away from the team. Saving Changes...
Priya, I respect your views, I am sorry if I have offended you in any way. Nowhere have I said that I want to limit the options for the team. I only said that contract may include generic boundaries as to what kind of (agile) tools are permissible to do the job and they could be many, out of which agile team will pick their selected ones. You see there are a number of agile methodologies in market and contract may mention that you would be following SCRUM or CRYSTAL or whatever. And also within whatever methodology, some specific tools can even be mentioned as permissible. The team is at liberty to choose their tools and make their estimations for each iteration. But I am sure they are not going to be inventing some new tools at the spot out of thin air. Hope this clears the air.
Sorry the last post was not for Priya but Alistair. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Hi Suhail, don't worry, I'm not offended!
I appreciate the clarification, but if your earlier post stands, I would say that defining "what [a]re the various agile tools and techniques permissible for this contract" is more than just "generic boundaries" and would normally be interpreted to mean you are specifying permissible tools and techniques. The corollorary of this is that some other tools and techniques are not permissible and are therefore proscribed.
Of course, that's what we pay lawyers the big bucks for, right? To make the language in contracts clear and understandable? Saving Changes...
