Can you combine fixed price and agile?
Many clients prefer fixed price outsourced IT projects to other contracting models and understandably so. It allows them to finalise budgets upfront, and transfer the inherent risk of IT delivery to the supplier. But with Agile methods for software delivery now commonplace, it poses the question whether this pricing model still applicable in an Agile world. Is it still possible for a client to fix costs and transfer risks to a supplier, whilst still retaining the flexibility and efficiency that Agile gives them? Roger Gibbon, Head of Delivery at Reed Professional Services gives his insights.
According to the Project Management Institute around 70% percent of organisations globally now use some form of Agile methodology. With many companies now over the hurdle of embedding Agile into their organisation, focus is now turning to how best to engage suppliers to deliver fixed price development contracts within an Agile environment. The concepts of Agile and Fixed Price are fundamentally polar opposites, one is creative and flexible, and the other is rigid with fixed parameters, and there is much debate as to how this problem can be solved effectively to bring these two worlds together.
Traditionally a fixed price development contract has actually meant fixed price and fixed scope. Requirements are defined up front, and a fixed price is provided to deliver them. Defining requirements up front in an Agile environment to fix scope doesn’t make sense. Agile is designed to allow us to ‘create’ software products iteratively and allow them to evolve with close collaboration between technical teams and product owners. When we have tried this traditional approach with our clients it has stifled the creative purpose of Agile, and time has been wasted managing inevitable scope change control. Luckily, this is not the only option.
We need to change how scope is defined so that it becomes partially variable, whilst retaining a level of control. In Agile environments the most common way of recording and tracking scope is as a set of User Stories (capturing the ‘who’, ‘what’ and ‘why’ of a requirement in a simple, concise way), recorded into a Product Backlog, and prioritised into the order they are to be delivered in. Because the product backlog is an open collaborative document that can evolve throughout the life of a project, it provides the product owner with the flexibility to add, change, remove, or re-prioritise the remaining user stories. This is usually done based on the feedback and review from earlier iterations and as the understanding of the product being developed increases throughout the lifecycle of the project.
It is this flexible and collaborative way of working between the product owner and the technical team that is at the heart of Agile, and that needs to be retained when creating a Fixed Price Agile contract.
To solve this at Reed Professional Services, it required us to take a deliberate shift in thinking. Rather than fixing the ‘what’ element of scope (i.e. a specific list of User Stories), we instead needed to fix ‘how much’ of that scope can be delivered (i.e. how many User Stories, or more specifically Story Points). By taking this approach, we enable the client to retain the flexibility around scope whilst staying in control of costs and ensuring the transfer of technical delivery risk to us.
To give us the full picture, there are a number of factors that we need to determine:
We prefer to estimate in Story Points, rather than ideal hours or any other metric, as we find it speeds up the estimating process and also provides a better metric for the fixed price contract (other Agile estimating metrics can work equally well). It’s best to have reference user stories for effort and complexity comparisons so that everyone is estimating from the same baseline.
The ‘definition of done’ also needs to be articulated in a clear statement, to define the criteria by which a story point will be assessed for completion. This forms the basis of a checkpoint at the end of each sprint, and creates a quality baseline for reference with the client, much like the Quality Policy in a waterfall approach.
Team Velocity, is the measure of how many story points a team can deliver within an iteration or sprint cycle. There are many factors that can affect team velocity, and the velocity will vary from team to team. Ultimately the best way to determine it is from past experience and historical metrics of the team. It’s important to get this measure right, so you should adjust it over time and from project to project, as understanding improves.
Let’s assume our Team Velocity is 50 story points per two-week sprint. If we know that the total story point count for the product backlog is 600, then we know it will take us 12 sprints, or 24 weeks to deliver. This then gives us the primary parameters for our fixed price contract. We can commit to deliver 600 story points worth of completed product over 24 weeks. So it is the total story point count (the how much) that we use, rather than the user stories themselves (the what). From this we can calculate our costs and determine a fixed price.
Crucially, if the client then wishes to add or change any of the user stories in the product backlog during the project, they can do so. Either lower priority stories can be dropped so that the total story point count remains at 600, or additional sprints can be added to increase the story point count. Contract change control is easy, because it’s simply a record of any story point count change and the associated cost change, rather than the constant update of scope items as we would have previously faced. A record of scope is still recorded in the product backlog.
Our team here at RPS have found this to be a very effective method for providing fixed price Agile development contracts to our clients. It has increased our productivity and efficiency, therefore lowering costs. As a result of implementing this process we’ve reduced the time spent in analysis at the start of the project to determine how to get to a fixed price, and reduced the time expended on change control. The feedback from our clients is that we can work more collaboratively, whilst they feel more in control.
