I am quite known in my Sircle to be a book eater! This week was dedicated to "Agile Contracts, Creating and Managing Successful Projects with Scrum". I wanted to make a sumary here, since I reckon that this subject may interest other Sircles too. All images are taken from the book, to which I remind for further details, explanation and a lot of practical examples.
The main problem inherent in all software development is the variability as to what should be delivered: the inhability of the customer to exactly know what they actually need. Despite the know weaknesses of traditional tendering process, and classical implementation approaches, it is very common to hear some statements, often linked to the rejection of an agile contract model and the tendency toward a fixed-pricer contract:
- "I want to know what I get for my money!"
- "How can I be sure that you will not inflate the price? You can simply work more slowly"
- "I need a work contract, so I can capitalize the investment" We, as software providers, should offer a product that the customer wants at a higher price than a product that the customer does not want. Customers want the cheapest provider, but they actually don't know what they really want, and the details of the scope will change during the project for various reasons.
Typical types of contracts
Even though we all face these problems every day, still the fixed price is the most commonly used contract in the IT world. It is governed on the basis of a scope that is complete and specified in full detail according to compensation, acceptance and delivery date. The contract is based on the assumption that customers know what they want to have delivered. Problems with this type of contract:
- wrong assumptions
- wrong expectations
- wrong timing of detailed requirements
- wrong requirements
Time and material
This contract is usually governed on the basis of experience levels (e.g. junior, senior) and roles (e.g. analysts, testers, developers etc.) and the subsequent cost for unit of time of delivery within the framework of a project . Problems with this type of contract:
- micromanagement and supervision
- sales process is based on best people, but they may not be available when contract is awarded
- should be based on performance, not on time
The missing piece: an Agile fixed-price contract
The Agile fixed-price contract balances the interests of suppliers and customers, by creating a new contract in the form of a cooperative model for implementation, that does not set aside clear goals and a framework for achieving them. This is done by combining principles of cooperation and flexibility in designing the best possible requirements. In terms of budget and cost, it incorporates a price ceiling. This agreement provides a clear method as to how parts of the scope (split in sprints), based on the overall concept (product backlog) are defined and implemented, but the agreement contains no final detailed specification.
An Agile fixed-price contract defines a contractual framework within which time and costs are agreed upon, as well as a structured approach to steer the scope within boundaries and by processes, in a defined and controlled manner. An agile fixed-price contract therefore includes scope control, which makes a decision possible as to whether a specific feature should be more or less complex, or whether it needs to be made at all. This approach:
- reduces the knowledge decay
- simplifies adaptation to changes of scope
- allows a quick project start
- changes in project scope are possible, and are provided at no extra cost
- a common approach to cost estimation and deliberate governance is agreed to contractually
- it is a cooperative agreement that keeps motivation high for all sides involved, and leads to project success
But how is an Agile fixed-price contract set up?
- Define the contract at the level of product or project vision, topics and epics from the perspective of the user (i.e. to a level at which the contract is complete but not yet described in detail)
- Specify the details of an epic down to the level of user stories
- In a joint workshop, make an overall estimate of the effort required, starting from the above set of reference user stories, including the risk of implementation and business value for these user stories. The result is an indicative fixed-price range
- Fix the riskshare, exit points and checkpoint phase. This agreement states also that after the checkpoint phase, the indicative fixed-price range is converted into real
- Agree on the scope and expense management process, and the governance of the decision-making process
- Agree on a motivational model and a cooperative model, consider a bonus system
An agile fixed-price contract is the type of contract with which a client can achieve the greatest benefits, and can build strategic partners.