Loading...The vast majority of the Pentalog projects are developed in an Agile mode, which always raises the same issue: adapting the contractual framework to the new Agile context. This issue is even more difficult in the case of fixed-price contracts. This article aims to present certain possible solutions that are generally a good compromise for all parties.
Contracts are meant to cover, among others, the moments when there is no communication whatsoever between the two parties. They reflect our hopes and fears, and each party tries to build protection walls that will most likely come in handy in case of dispute. However, what these walls do is ultimately reduce the created value and can be a real problem on the long term, especially in a world where only businesses that maximize value will survive. By convention, contracts must limit the opportunistic behaviour of both parties that are inevitably looking out for their own interests. According to the Agile vision, each party should act in good faith and their relationship will naturally limit opportunism.
Fixed-price contract: a genuine fake security label
As for traditional fixed-price projects, the client is not protected even if the provider is usually the one bearing the most important risk. In fact, the client generally chooses the lowest price at the expense of the rest, a price often offered by the most “desperate” or optimistic provider. Both cases present risks related to the misunderstanding of the project’s complexity, and in the end, to contract abandonment. Due attention should also be paid to cost increase as a result of risk estimation (for competent providers), delays, lack of quality (for less scrupulous providers), and excess of features. The latter should protect the client but in the end, it generates applications with more than 60% of rarely or never used features (cf. a study conducted by the Standish Group and presented at the XP2002 conference by CEO Jim Johnson).
The Agile contract: the alternative
From what I’ve seen, new clients usually tend to develop their first project in fixed-price mode, with a fixed scope and budget. The underlying reason is quite easy to understand: the client first wants to test its provider without too many risks involved. On the other hand, given the already existing risks related to this type of contract, I think that adopting the Scrum organization is a much better choice, one that is not otherwise inconsistent with the fixed-price concept.
There are two preconceived ideas about Agile methodologies:
- Project requirements are not known before the first iteration. These requirements can be known following the Release planning or the initial version of the Product Backlog, containing all the clarified and estimated requirements. The first sprint can therefore start without problems in a defined and estimated scope.
- These requirements must change in an Agile framework. We have to understand that the Agile framework actually provides an opportunity and the mechanism to integrate changes allowing us to adapt. Having said this, no one is forced to use this framework. The content may remain fixed. But the Agile framework will always bring advantages such as transparency, frequent feedbacks, limited lots, less waste, less waiting time and less work in progress time, etc.
Scrum implementation brings flexibility in the fixed-price framework: this merely translates into the possibility to replace the existing requirements with new equivalent ones in terms of workload and changing the implementation order of these requirements.
Considering the above, I call for limiting the duration of this first fixed-price contract in order to avoid the quite common quality nonconformities. In fact, this is the only adjustment variable on a project where scope and deadlines are defined in advance.
The solution: successive contracts
One way of closing a deal fully synchronized with a win-win organization is by signing successive contracts, as explained by Greg Hutchings in Contract Evolution on a Large Agile Project. In the example shown in this article, contract evolution is not predicted from the beginning for it is the consequence of the client/provider relationship evolution and, subsequently, of the project maturity level.
Here are the four types of contracts he predicts:
- Contract with a fixed price and scope: this is the traditional type generated by the lack of trust between the two parties. As indicated above, to limit the important risks, we should avoid the sequential cycle and decrease contract duration.
- Contract in a dedicated team mode per iteration with bonus / malus: this type of contract is carried out in Agile mode and generates more trust on the client side as it accepts the dedicated team mode (more financially interesting). However, the client wants to maintain “control” by making the most of two parameters: quality of deliverables and team velocity. These factors can either improve or lower the final price. I clearly prefer the first case, but this can nevertheless have a negative influence on transparency and on certain team “games” which will do their best to avoid the malus case.
- Contract with fixed prices per unit of work: in this type of contract, the bonus/malus system is eliminated. The client and the team must integrate very well the concept of unit of work: relative points associated with use cases. The cost of each iteration depends on the number of relative points delivered at the end of the iteration. I agree with Greg Hutchings when saying that this type of contract is ideal for each party. On the other hand, a good estimation based on the unit of work requires a more detailed analysis and a two-sprint lag compared to the implementation sprint (the N sprint analysis and estimation are done in the N-2 sprint).
- Contracts in a dedicated team mode – capped per iteration: this type of contract is well adapted to the maintenance phases. The client has an annually fixed budget and a variable scope.
Of course, there are many other types of contracts explicitly including risk and/or loss/profit sharing which ensures a perfect alignment between both parties’ objectives and engages the win-win philosophy. I will give you more details about these contracts in a future article.
Finally, I completely agree with Craig Larman who says that good contracts are those supporting the implementation of Agile values such as transparency, collaboration and implicitly, trust. I consider trust the key element which, once earned, lightens up the contractual model to ensure one of the Agile Manifesto four principles: “Customer collaboration over contract negotiation.”, and thus maximize the produced value.
Sources:
- “Practices for Scaling Lean & Agile Development”, Craig Larman, Bas Vodde
- “Agile Contracts”, Mary Poppendieck
