Agile Approaches and Fix Price Contracts

The difficulty with contracts is that it is about trust. Here lays the roots for success or disaster.

If no trust exists the henceforth dread process is established. After tough negotiations the development team starts but does not collaborate with the customer. They just build what is written in outdated requirements. A subpar product is shipped and the relationship with the customer is deeply damaged.
We can do better. We shall collaborate, trust each other and create an awesome product. This is the essence of "being agile". How shall we be agile and work the lean way in a contractual environment? By contractual I mean no time and material approach.
We shall 

• Define and rapidly realize the minimum viable product MVP. It defines success and build trust. Use this MVP as anchor during contract negotiation.
• Prioritize Money, Time, and Scope. The most important item - and it can only be one - is the basis for the agile contract,
• Service is the essence of software product development. So your agile contract shall be a service contract. Select a rolling contract approach to deeply involve both sides,
• Fail early and learn. The disputes between contractor and customer shall stay reasonable due to the smaller amounts in play.

Contract

Initial success is the timely realization and deployment of the MVP. The MVP is the anchor of trust. Use rolling contracts to extend the product.

Priority on Money 

Frame cost as investment and discuss value with the customer, not just money. Fix the budget - money dimension - and have some tentative milestones. Therefore we must invest to prioritize the stories and talk about your MVP. Often nice to have functions are never realized.

Priority on Time

Sometimes, it is not about the cost. Instead, there is a deadline, like the end of the fiscal year.
Fix the project milestones - time dimension -. We still must define a budget and prioritize the stories. The must stories shall be implemented before deadline and budget can be extended to respect the deadline.

Priority on Scope

And in other cases, the scope actually is quite defined, and both money and time are flexible. In these cases, it makes sense to fix the scope variable.

Fix the functionality - scope dimension -. Budget overrun and delays are possible. Defining the scope in advance is less agile. You assume you already know everything about the product to build.

The contract defines a service. The delivered product is the output of the service contract but not the sole item of the contractual binding. 

Tracking

Signing a contract is the easy part. Now you must track progress, manage changes, and reach the agreed goals in a timely and economical way.

• Commit in trust, training, and decision making. Train your people and customer's representatives,
• Deliver incrementally every few weeks to prove progress and cement trust,
• The more trust you build, the less escalation you will have during the project, 
• Have rolling planning, budgeting, and tracking. You shall gain visibility of progress, transparent costs, and tentative end for fulfilling the contract,
• How do you track and document changes? How do you inform your stakeholders about contract changes?

The later questions are solved differently based on the level of trust between the contractor and the customer. Try to avoid a full fledged change management process and systematic escalations.

Work Approach

The agile manifesto states

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Here the approach to define and finalize a fixed price agile contract. And please remember the manifesto, it is all about collaboration and responding to change.

• Create the product vision and initial backlog together. Write good epics and identify main topics - topics identify the minimum outcomes to maximize product value -,
• Commit to the vision and defined MVP,
• Define a budget for the project,
• Define tentative deadlines,
• Refine some epics and write the stories. Keep them concise and clear,
• Estimate the product backlog together with the customer,
• It is all about cooperation and adaptability,
• Use relative estimates to classify stories, use story points,
• Talk about business value and implementation risks,
• Finalize the contract,
• What happens if costs overruns happen - We suggest to share the costs and define the percentage each party shall pay, if the supplier pays 0% it is a time and material contract, if the supplier pays 100% it is a fix price contract. Aim for 50% -,
• Define a checkpoint to validate the estimates and hypotheses,
• Define exit criteria and exit points for both parties,
• State governance how to simplify scope and stories to respect budget. State and agree upon escalation process if no agreement is found,
• Invite the customer to the Scrum sessions. Sell the entire Scrum team and not individuals,
• Sell releases containing a small set of sprints,
• Deliver and deploy the build solution,
• Have the end users use the deployed product.

The Scrum master, the product owner and the team shall perform these activities. Never use external consultants or business analysts. The ones writing the stories and estimating them shall implement them.

Fallback

Hide the fact you are working the agile way. Don't tell the customer you are working any differently to normal. Clearly state internally why you do it and why your corporate values allow this solution.

Estimate and plan the work as you would normally, sign a perfectly normal contract, then use Agile techniques and especially XP techniques to improve delivery.  You need to have a "don't ask, don't tell" type policy because basically you are lying.

Conclusion

The most successful projects I worked for had selected the money dimension seen as investment budgets. Goals correction were communicated early and the contract amended accordingly. We avoided complicated and expensive change request processes. 

The build products were very successful. We respected the agreed budget and were timely. The dynamic was in the scope definition. We delivered early and often high quality increments so the end users could adjust their expectations and refine their needs.