Agile Project Contracts and the Trust Factor
Join the DZone community and get the full member experience.
Join For Free1. Fixed Price and
2. T & M (Time and Material)
While working on Fixed price model,
software vendors would analyse the requirements upfront and commit to a
price with the customer. Many a times, the customer fixes a price and
the committed bidder gets the project.
The uncertainties involved in the software development makes this model a flawed one. As per the popular and well researched Cone of Uncertainty, the initial estimate done at the beginning of the software project could be +/- 400%
off-mark
than the actual calculated at the end. In order to mitigate these
uncertain risks, companies participating in these contracts have to add a
lot of unscientific buffer to accommodate them.
Projects
applying Agile methodologies is supposed to have a flux associated with
them. The scope could change any time and this needs to be accommodated
in the contract and this is not easy. This is one of the reasons for
Fixed price contracts not being popular in Agile projects. Even though
there are several case studies of application on Agile projects but at
the end of the day, the constraints imposed by Fixed Price model might
actually destroy the agility.
Photo Courtesy: http://www.construx.com/Page.aspx?cid=1648
Time & Material(T & M)
as the name implies is supposed to work well for Agile software
development as it has no restriction on price or scope. The customer can
keep paying as long as the value is getting delivered. However, my
observation has been that this model works well in an established
trustworthy environment.
Several experiments have been
made in creating contracts specifically suited to Agile environments.
Some of them include:
1. Phased Delivery
2. Capacity Based
3. Value Based
Phased Delivery contracts
divides the entire project life cycle into multiple different phases. A
goal is set for each phase and funds are released based on the
delivery. The goal could be the number of user stories to be delivered
in each phase providing additional quality related info.
Capacity based contracts would provide X number of people for the project and no scope related delivery constraints are signed.
I am also envisioning Value Based Delivery contract, and
I am not sure if some one has experimented with this. I feel that,
either a $ value or some unit could be assigned to Epics or to user
stories theme. As and when this gets delivered, proportionate amount of
fund could be released. Again, quality related matrices could be an
additional parameter in the contract.
An Agile practitioner has put together a list of 10 styles on Agile contracts . check this link out for more details.
Summary
I
strongly believe that Trust and Contract are inversely proportional to
each other. That is, as long as we have less trust, we need more
contracts.
source: http://agileworld.blogspot.com/2011/11/agile-contracts.html
Opinions expressed by DZone contributors are their own.
Comments