Fixed Price Agile – the secrets revealed
Fixed Price Agile Software is the aspiration of most CIOs. It offers the financial predictability of a fixed price combined with the flexibility of of an Agile approach to software delivery. Agile allows the team to work in a manner that adapts to change, that encourages and responds to fast feedback on working software. Many argue that fixed price and Agile are mutually exclusive. This is understandable, because agile embraces the idea that requirements change, whereas a fixed price would typically presume inflexible and pre-known requirements. In this article you will learn that fixe price and agile are not mutually exclusive if the work is structured in a particular way. By the end of this article you will have learned the secrets of how it can be done.
Requirements Change is Inevitable (and measurable)
It is virtually impossible to know all the requirements for a software project before starting. Requirements change during the project and the course of the project needs to adapt accordingly. The reasons that requirements change are two-fold:
- Unforeseeables. We live in a rapidly changing world and some requirements will be unforeseeable, simply because circumstances and needs change. Although the volume of change can be anticipated.
- Unknowable unknowns. We can’t know all the details of what needs to be built until we have done some of the work. Some requirements only become apparent as the project evolves.
For a well-managed project, the volume (we recommend quantification using functional size) of these changes should typically be around 2% per month. High volatility of requirements can be perilous to a project. Consider a project of 12 months with 5% per month requirement churn. This means that the final project will be 60% different from how it was conceived and at least half the code will be written twice or more times. This is not uncommon for an Agile undertaking. Agile helps the customer get value from delivered software but is not necessarily the most efficient means of getting there. One of the catalysts for Agile emerging is the challenges of performing sound requirements work up front. This is where AI is changing the landscape.
Proactively Manage Change of Requirements
Any change in requirements is likely to disrupt the flow of the development team(s), and so every effort should be made to proactively manage change, whilst at the same to accepting change will be necessary and should be accommodated. Minimising change requires the following:
- A contract structure that encourages both parties to drive for quality requirements as early as possible, discouraging avoidable rework.
- Solid metrics for sizing, costing and planning changes.
- Lightweight change management and prioritisation processes.
Commercial Norms are Not Satisfactory
The most common commercial approach to outsourced software work is to “pay for a team and they will work through the backlog according to the priorities, releasing updates on regular basis.” This tends to be the nature of most Agile contracts, delivering what the customer deems most valuable at any given time BUT provides no assurance that the entire scope can be delivered for a known cost nor in a given time frame. This arrangement is commercially asymmetric, with the buyer carrying most of the risk associated with delivering the project. Worse still, there is a commercial incentive for the developers to encourage requirements volatility as this generates rework, more fees and longer schedules. In short, the incentives of the two parties are not aligned. This is how most contracts are structured.
Characterisics of a Fair Fixed Price Contract
It is vital that the contract is designed to incentivise positive behaviours. From the buyer’s perspective, a fixed price software development contract will have these characteristics:
- Aligned incentives and shared risk.
- Incentives for both parties to maximise delivery of high quality software in the shortest time for a fair price.
- Permits flexibility in scope, yet challenges the necessity of each change.
- Does not require all requirements to be known up front.
- Allows the buyer to predict costs and timelines.
- Rewards good behaviours by both parties (and penalises bad behaviours).
- Allows the developer to embrace flexible working practices.
Can this actually be achieved? Yes. It can and it has been done many times with successful outcomes from both sides.
How to Implement a Fixed Price Agile Software Project Paradigm
By embracing the following guidelines, CIOs can achieve superior predictability and simultaneously increase their output of high quality software for a given cost.
Development shops, integrators and others who sell software services on a time and materials basis may not leap to adopt this approach, so it is incumbent on the purchasing party to introduce the changed approach.
For CIOs seeking to achieve the combined benefits of Agile and Fixed Price contracting, we recommend that the following principles are understood and then the practical steps are followed.
Principles of Fixed Price Agile Contracting:
- Standardised objective sizing with a fixed price per unit,
- Agreed progress metrics
- Quality guardrails to ensure both parties support each other achieving good results with least overall effort.
- (Optional) – incentives for developers to earn a bonus for exceeding agreed progress metrics.
Fixed Price Agile in Practice:
Functional size-based contracts use a firm fixed price per standard functional unit. Regardless of what functionality is delivered and how (whether using hand cranked code, or or re-used). A mutually agreeable price is set with a supplier for an arbitrary amount of functionality, but not the specific functionality. Firm fixed cost per CFP– allows for the flexibility of changing requirements, combined with cost predictability.
- Use ISO Standardised functional sizing. Invest in learning the modern standard for software functional sizing (ISO standard COSMIC function points CFP).
- Use AI-first requirements analysis and sizing to accelerate and improve requirements quality. AIFRA raises the quality and completeness of requirements before work begins, that provides the buyer with a good understanding of feasible costs and durations. It’s a step towards “big requirements up front” but without the downsides of time consuming requirements documentation work.
- Functional size-based contracts. Carefully structure contract terms that encourages the behaviours described above.
About COSMIC Function Points
COSMIC function points are the second generation of functional sizing and the first to achieve ISO standard recognition. They are a technology agnostic means of sizing software. CFP are the basis for better metrics and control of software scope and activity. The units of CFP are closely aligned to the effort it takes to deliver the functionality.
About AI-First Requirements Analysis (AIFRA)
AIFRA is tooling that accelerates the analysis, and quality of requirements (especially: clarity, completeness, consistency and conciseness). By using these tools, companies can specify scope quickly to a higher standard than doing so manually. Importantly AIFRA performs three key things that unlock fixed price Agile contracting:
- Accelerates early requirements refinement.
- Exposes knowable unknowns – a major cause of scope underestimation.
- Automates the size estimation without even distracting the team from their work.
Fixed Price Agile Contracting that Works
The agreed price per CFP will be set and remains unchanged during the project. There should be contracted guidelines for the client to present clear requirements in a timely fashion and suitably measurable quality. In return the contractor will deliver the functionality at an agreed rate, to an agreed measurable quality. There may be incentives in the contract for the supplier to earn a bonus for a faster delivery (at the agreed quality level). There may also be cost penalties on the client for presenting poor or late requirements (changes). Overall contracts structured this way can deliver the dual benefits of Agility and a Fixed Price.
What doesn’t work
Story Points
Contracts based on Story Points. Why? Story points are highly subjective and easy to manipulate during the project. Usually the developer determines the meaning of a story point and then manipulates estimation to suit their commercial interests.
Outcome Alignment
Aligned business outcomes. It rarely possible for the customer to align the rewards of the developer with the business outcome of the client. Usually there are too many characteristics outside of the control of the developer. Contract negotiations tend to collapse. On some (rare) occasions though, this can work.
How to proceed
If you’d like to learn more about how to achieve Fixed Price Agile contracts, contact us,
ScopeMaster Ltd offers both the tooling for automated requirements analysis as well as professional services on how to structure fixed price agile contracts.