Agile Approaches and Fix Price Contracts

2017-10-02

Tags:

Agile

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

If no trust exists, the henceforth dreaded 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 solution 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. This product defines success and builds 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 application 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 contractors and customers 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. We must invest to prioritize the stories and talk about your MVP. Often nice to have functions that 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 product milestones (time dimension). We still must define a budget and prioritize the stories. The mandatory stories shall be implemented before the deadline. The 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 overruns 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 to 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 product.
Have rolling planning, budgeting, and tracking. You shall gain visibility of progress, transparent costs, and a tentative end to 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 changes over following a plan

— Agile Manifesto
2001

Here is the approach is to define and finalize a fixed price agile contract. 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 the main topics. Topics identify the minimum outcomes to maximize solution value.
- Commit to the vision and defined MVP.
- Define a budget for the product.
- 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 cost overruns happen? We suggest sharing the costs and defining 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 an 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. Do not 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. UseAgile techniques and especially eXtreme Programming to improve delivery. You need to have a do not ask, do not 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. Goal correction was 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.