Is There Inherent Incompatibility Between Fixing Price & Schedule And Adopting An Agile Approach To Software Development? No, But It Is A Challenge That Requires A Best Practise Methodology
The service term fixed price Agile has become established enough that it even has its own Wikipedia entry. But for anyone familiar with the concept of the agile methodology, in the context of software development or any other application, merging the concepts of ‘fixed price’ with ‘Agile’ will raise an eyebrow.
Agile is all about not writing things in stone and changing a project’s parameters and details as it progresses, based on what has been discovered.
Firm Fixed Price projects are very much about writing things in stone. The customer demands clarity on exactly what will be delivered, by when and at what cost.
Agile advocates argue that the practical outcome of adopting the methodology for a project is that there is actually a much higher chance of it being delivered on time, in budget and achieving what it was intended to. But even if that were true, and there is plenty of evidence to suggest it is, for a project’s sponsor, traditional agile can be a leap of faith.
“You insist that by not defining or contractually committing to the project’s scope, budget and deadline, we have a better chance of a better product being delivered in budget and on time? And if it isn’t, that’s good too because it means the original deadline and budget were wrong?”
You can see the problem. Not an easy sell. Except, the agile approach has established itself as the dominant approach to software development, especially in the context of big, complex projects that employ scaled agile frameworks. Because as a general rule, it has been consistently proven, in the field, to deliver results. Most crucially, an agile approach, as we’ll see, goes a long way towards negating the risk of white elephant projects.
But that doesn’t mean project sponsors can throw time-to-market and cost parameters out the window. In the real world, a software development project will only deliver organisational ROI if it is able to do what it is supposed to, by a certain point in time and up to a certain price point.
The sponsor also understands that nailing exact technical specifications, deadline and budget to the floor before the project has started, and not allowing for any deviation, massively increases the risk of the delivery of software that is not fit for purpose.
In this context, it is obvious to see why the concept of Fixed Price Agile, is attractive. It promises the best of both worlds. Enough flexibility to ensure the end product delivers the organisational benefit it is intended to. Without the risk of it being delivered to a deadline and at a cost that negates the net positive impact on sponsor’s organisational goals.
But is it actually possible for a development team to execute a project in an agile fashion while still absolutely committing to a deadline and budget? Or is Fixed Price Agile a perfect example of cognitive dissonance?
In this post we’ll outline the competing priorities of agile and fixed price software development projects and to what extent they can be successfully unified under the hybrid methodology of Fixed Price Agile. We’ll also present why our preferred term and approach is the subtly but meaningfully distinct ‘Controlled Agile’.
Are Agile And FFP Compatible?
Agile methodology is described as an approach or mindset, rather than a step-by-step process. The core concept of an Agile approach to software development is that it is an iterative process. A larger project is broken down into bite-sized pieces, referred to as sprints. Each sprint is made up of development tasks grouped together in a way that should mean the outcome of a completed sprint is a new layer of tangible, working results has been added to the software.
Overall requirements, such as functionalities and user experience, are reviewed at the end of each sprint and upcoming sprints adjusted. ‘Tune and adjust’ at regular intervals is the maxim and “welcome changing requirements” is one of the 12 principles of Agile projects.
The 4 Agile Values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Number 4 of the ‘Agile Values’, “responding to change over following a plan” also highlights the inherent fluidity of an Agile software development project.
Agile Sounds Like A License To Over-Run Development Budget And Deadlines
Sceptics might well argue the adaptive, iterative agile mindset sounds like a license for development projects to over-run on budget and deadlines. If little to nothing is set in stone from the outset, in terms of the project’s scope, and by extension timelines and budget, how can an organisation plan or analyse if the project will deliver net value?
An agile advocate will respond that the actual outcome of adopting an agile methodology is that the evidence shows the inverse is more likely to be the case. Especially when it comes to large complex projects.
How so? In a large, complex software development project it is almost impossible to accurately plan every detail in advance. There are multiple examples of hugely expensive white elephant projects that are granularly planned in advance but once the plan has been executed, it becomes apparent:
- The software was supposed to deliver a technical solution that doesn’t work as intended,
- The software delivers a working solution that that nobody particularly wants to use, or
- The software delivers a working solution that ultimately provides little or no added benefit.
Large organisations such as banks and government departments are famous for white elephant projects that come at an exorbitant cost. Two of the most notorious examples from the UK are detailed by the management consultants Citi:
£500M – E-BORDERS PROGRAMME
Among the most prominent reasons this project failed was that the requirements were not accurately detailed, and the project was planned on the basis of assumptions that ultimately proved ill-founded. For example:
- When the system was ordered in 2007, no one in government realised that the objectives were illegal under EU law
- The pilot was only tried at airports and it was assumed the system would work at ports and the Channel Tunnel. It didn’t.
£10BN – NHS CONNECTING FOR HEALTH PROGRAMME
From its inception in 2003 it was realised that this was a large and significant technology programme, quoted as “the world’s biggest civil information technology programme”.
In such a large and complex IT programme run over several years, it is impossible to isolate a single point of failure. Reservations were being raised as early as August 2005, and the programme was not cancelled until July 2011. However, two points are uncontestable:
- The scope of the programme was huge – too large to be readily managed by even the most experienced team
- End-user buy-in was not managed, and support among stakeholders was consequently very low: in 2008 two-thirds of doctors said they would refuse to have their own medical records stored on the system!
Of course, these two examples are particularly spectacular examples of huge sums of money, time, effort and opportunity cost being wasted white elephant projects. But anyone who has worked in software development for any period of time will be familiar with projects delivering technology solutions that don’t work as intended, are not used or are used but fail to genuinely improve anything.
Those are pitfalls that even much smaller projects can and do run into.
The agile methodology was designed as a way to avoid white elephant projects. Rather than planning a full, sprawling software solution from beginning to end in meticulous detail, building it, and then discovering it either doesn’t work as intended or isn’t actually very useful, the project is built in iterations of working components – sprints.
Each sprint should result in working, testable software. A ‘minimum viable product’ that can then be assessed for efficacy of functionality, usefulness and contribution to the end goals of the whole project. If one sprint produces a baby white elephant, it can be set to the side at a relatively minor cost without compromising the value of previous or future sprints.
In a traditional ‘waterfall’ approach, if something is wrong slap bang in the middle of the end-to-end planned and completed software, a large part of the whole thing might need to be pulled apart and put back together. Or, as is often the case, the project might be given up as a bad job because fixing it would cost too much or take too much time.
Agile Sounds Perfect, Sign Me Up! But I Still Need A, B & C By June And My Budget Is….
An agile, iterative approach to software development sounds sensible, functional and, done right, a fool-proof way to negate the risk of an embarrassing and costly white elephant or less than optimal projects. And it is, which is why it has become the dominant software development methodology.
But it also introduces friction between how organisations plan their finances and business strategies and how they develop software. Most organisation have a time and cost budget in mind when they plan a new project, for internal efficiencies or as a product for third-party users.
Beyond those parameters, the project might well no longer be time or cost-effective because the window of opportunity will be lost or the financial return on investment no longer stacks up.
That means an agile methodology still has to take timelines and budget into account. In most cases budget and timeline constraints can’t simply be discarded because ‘that’s not how agile development works.’ Time-to-market and budget are still important variables that have to be managed.
Fixed Price Agile – Can You Have Your Cake And Eat It?
Which is why the concept of Fixed Price Agile is presented as a solution. It infers that decision makers can keep all of the advantages of an agile approach, without having to contend with the inherent fluidity the infers for budget or deadlines. With fixed price agile, we can have our cake and eat it.
Except, of course, that’s unfortunately logically incompatible. If all three sides of the development triangle – scope, time and budget – are fixed, what’s agile about the methodology? It would seem the only option would be to turn the triangle into a square, with the fourth side ‘quality’. But what organisation will agree to quality being the only acceptable variable?
Which leaves us with a final hope. Can an agile approach be tamed to the extent it is a viable fit with Firm Fixed Price Projects (FFP). Is Fixed Price Agile a unicorn or a tweak to agile that can effectively offer enough of the benefits of both models to deliver value added, functional software that meets budget and delivery deadline requirements?
FFP agile requires some give and take. We believe a more accurate term is ‘Controlled Agile’. But it is a perfectly viable methodology when fully understood and correctly structured by both a project’s sponsor and the team responsible for its delivery. Here’s how.
Fixed Price Agile, or Controlled Agile, Is A Platypus, Not A Unicorn
The core friction that a Fixed Price Agile methodology has to address is, as fixed price, not allowing changes to the project’s business constraints of deadline, budget, added value. While, as agile, the team working on the project must respond to changes sprint iterations dictate are necessary.
How does a single methodology both prevent change and welcome it?
The key to answering that question is to pose another. Change from what?
The Project Management Institute (PMI) has one of the clearest outlines of how the alliance between fixed price and agile pivots on the ‘change from what?’ question. The first step to arriving at the answer is to take a step back and define 3 other terms:
- Seller Proposal: All projects compete for resources. A proposal is the key means we use to articulate the business value proposition for a given endeavour. That business value proposition articulates high-level goals, and offers an estimated cost and schedule based on those goals.
- Contract: Once a given seller is selected based on the proposal, a “mutually binding agreement” is enacted to enforce the business constraints of the proposed project.
- Project: Finally, with a contract in place, a project team is chartered to execute our defined goals.
We have three distinct and sequential activities: proposal > contract > project. The contract enforces the constraints (scope, budget, deadline) defined in the proposal. So we can set that to the side and focus on how proposals and projects must be correctly created and aligned for a Fixed Price Agile project.
Proposals For Fixed Price Agile Projects – Best Practices That Minimise Risk
How do we create a Fixed Price Agile proposal that defines an estimated fixed cost and fixed deadline, that minimises the risk that the required and defined project results are delivered?
The single most important factor is to carefully define the project’s business success criteria. Firm fixed price projects prioritise completion on time and on budget. One of the strengths of the agile methodology is the use of ‘timeboxes’. The correct use of timeboxes should, in fact, guarantee the schedule and budget success of agile projects. But that does come with the necessity for the project to be adaptable on scope.
The Scope Of Fixed Price Agile Projects Must Be Set As Business Objectives
“If scope is malleable, it’s not fixed price”, is the obvious objection. For Fixed Price Agile to work, the underlying condition is ‘scope’ is defined as business objectives and not features. Features must be understood as ‘a means to an end’, and variable if we are to reconcile fixed price and agile as a viable hybrid methodology.
As the PMI nicely outlines:
“Rather than committing to the completion of specific work packages, a progressive proposal will discuss concrete measurable business objectives. If the project is intended to increase revenue or save operational costs, then project deliverables should have a measurable impact on those goals”.
It’s not about the features. They are a means to and end. Instead, define the target business criteria. Then, estimate the cost and schedule associated with meeting the business criteria. If we incur new complexities and risks during the project, we can de-scope features that don’t directly contribute to those goals”.
“Project success is much more likely when we are authorised to modify the project scope, in order to meet our bottom-line business goals within the fixed price and fixed schedule”.
Definition of Done
The most common point of failure for fixed price projects is the appearance of requirements not anticipated in the proposal phase. This, it is safe to say, always happens. The variable is how significant these unanticipated requirements are. Often unexpected requirements are not functionality requirements but are connected to other factors such as regulatory compliance, quality requirements and documentation.
A Fixed Price Agile proposal must clearly set out these expectations and a ‘definition of done’ clearly defined and documented. The ‘definition of done’ must articulate the point at which each functional element meets the definition.
If a clear ‘definition of done’, is missing there is a significant risk a proposal’s estimates will focus on high profile work packages, while neglecting less visible requirement that could potentially make a crucial impact on overall costs.
Execution Of Fixed Price Agile Projects – Best Practices That Minimise Risk
Once a Fixed Price Agile proposal and contract have been concluded, the project/delivery manager (or product owner etc.) takes over and is responsible for execution. In the best-case scenario, the person responsible for execution will have been involved in the proposal process. But even if that is not the case, their responsibility is to implement work packages within the fixed budget and schedule.
Re-Baseline
The first job of the leader of the now staffed project should be to immediately re-baseline costs and schedule. If the proposal has been done well, and the project manager involved, this process should be straightforward and involve only minor adjustments.
But if choices do have to be made because the new baseline indicates divergence with the proposal, this is the time to initiate the conversation of what trade-offs there is a willingness to make. A flexibility matrix can be a very useful tool in trade-off decisions. It focuses conversations and outcomes around trade-offs on predefined criteria.
Source: PMI
The “Dynamic Scope Option”
A Dynamic Scope Option, which focuses on technical specifications achieving business/organisational outcomes rather than a very specific and untouchable list of features, is necessary to successfully fuse the agile methodology with fixed price and timeline requirements. The project’s sponsor is protected against cost and schedule fluctuations without tightly restricting the space for innovation and the delivery of net value.
Including the Dynamic Scope Option is really what allows for a software development project to both adhere to an agile methodology and FFP requirement. The option allows the project’s sponsor to add a new feature to the sprint backlog (this could be either on the sponsor’s own initiative or on the advice of the project team) by removing another feature of equal or greater size. This provides the project’s sponsor with the flexibility they want, without compromising budget and time constraints.
Controlled Agile For Software Development
Some of the biggest projects we work on at K&C represent a subtle adjustment on the Fixed Price Agile approach – Controlled Agile. In our experience, Controlled Agile proposals and project execution remove some of the friction inherent in Fixed Price Agile.
What’s the difference between Controlled Agile and Fixed Price Agile? In theory, the difference is very subtle. But the practical impact of the adjustment can be anything from barely noticeable to significant. In a Controlled Agile project, the Dynamic Scope Option is extended to mean that if the sponsor wishes to add a feature to the backlog at the end of sprint iterations, they can do so. But without the obligation to remove another feature of equal or greater size.
The sponsor can, should they choose, opt to adjust budget, deadline or both to incorporate the desired feature as an addition to the scope, rather than remove another feature in a trade-off. This means the project team works with a Fixed Price Agile approach unless the project sponsor decides to alter budget or deadline in order to widen the scope.
This gives the sponsor the protection they want on cost and timeline and, at their discretion, the option to inject a little more ‘agile’ and a little less ‘fixed price/schedule’ into Fixed Price Agile. Controlled Agile makes the platypus of Fixed Price Agile that little bit more aerodynamic.
Make Sure Your Fixed Price Agile Approach Is A Platypus Not A Unicorn
The inherent conflict between fixed price and schedule and an agile approach to software developments offers a challenge. Changes in scope, schedule and cost must all be avoided but changes in risk, complexity, requirements and resources still responded to.
It’s not the most natural combination of competing priorities, but one that can be managed with a best practise approach to defining proposals and executing projects. To ensure your Fixed Price Agile project is a platypus not a unicorn, prioritise the following:
- Make sure both sponsor and project executioner understand the distinction between a proposal and a project, and take steps to reduce the risk associated with each.
- Proposals should include a clear “Definition of Done” for each work package.
- Collaboration between sponsor and executioner (whether inhouse or external) to develop project success criteria that focus on business outcomes as well as work packages for features.
- Consider a contract amendment to permit scope changes with the original budget and schedule constraints.
- Consider if Controlled Agile might work better than a pure Fixed Price Agile agreement.
