I’ve come to accept that most software shops now claim to be ‘agile’ whether they are or not. Many of them think that agile just means ‘being flexible’ but in reality, they do everything using the old-fashioned waterfall approach. I can accept that, but when vendors start offering clients ‘fixed price agile services’, and promising the flexibility and quality of agile with the safety and control of a fixed-bid project, they are doing a disservice to clients and potentially mismanaging their expectations from day one.
Managing a budget on an agile project is certainly doable, but what that really means is adjusting the scope and other factors to stay in budget. So, I’ve decided to take a stand against the whole idea of fixed-bid agile with the below statement:
“Fixed-bid agile is a confusing and misleading term and should be avoided”
Fixed Price Agile Is a Sales Technique
It certainly sounds good. The flexibility of agile without the risk of blowing the budget is a dream come true, and marketing teams are touting variants of fixed bid agile just about everywhere. It definitely attracts clients, but the methodology never seems to survive any scrutiny without turning into an ambiguous mess.
Take, for example, this discussion about how fixed price agile can succeed from Cognizant. Near the end of page 2, you’ll find that their recommended approach is to divide the requirements into ‘must have’, ‘like to have’, etc. and then apply the ‘fixed’ budget based on priority, leaving plenty of buffer in the budget to account for the unknown.
That’s not a bad approach but it’s not really fixed-bid at all. They are simply leaving some slack in the budget to make sure the critical path features get done with the allocated funds. In my world, we call that ‘helping the client to manage their budget through good planning’, and it’s not exactly revolutionary.
Another popular way of selling the fixed price agile dream is the ‘price per iteration’ concept. In this model, the client has a fixed-price (i.e. their max budget) and the vendor has agreed that the cost for each development iteration will have a fixed cost. This model offers few benefits to the client and is essentially the same as a regular time and materials project – calling it fixed-price is just a sales tactic.
Fixed-Price Agile Is Misleading
When a client hears ‘fixed price agile’ they assume that it means that they will pay a fixed price for the application they want to build. In many cases, a well-meaning vendor will tell clients that even with a fixed-bid project, they like to use an incremental (agile style) approach. Incremental development is a good practice and I applaud its use, but incremental development alone doesn’t make a project agile despite opinions like this one.
It sounds nice, but it’s just a fixed-bid, fixed-scope project with an incremental development approach – not very agile. And honestly, asking clients to completely lock down their requirements is very 1999.
Fixed Price Agile is a Slippery Topic
In every example I’ve seen, the explanation of how fixed price agile can work is esoteric and nebulous at best. Take this interesting but unactionable discourse about how sticking with high-level stories can help to stay within a budget – is this really helping clients who are trying to determine how to get the most for their money?
Almost every attempt to define fixed price agile seems to find its way to just a few topics:
- if the client agrees to fix the scope, you can fix the price (not very agile)
- Writing requirements is a difficult task with low ROI (not very helpful)
- Putting pricing on individual increments helps manage budget (not very helpful)
- Agile is great and works in every circumstance (totally useless)
For potential clients who might be lured by the promise of fixed-bid agile, run for the hills if your vendor is pitching anything that resembles the above statements.
What You Need To Know
Not everyone who is discussing fixed price agile is trying to sell you something. Many agile enthusiasts, myself included, are simply trying to explore ways to bring agile closer to the enterprise by offering better cost control and budget projections, etc. Some of the more seasoned agile pundits have made some very sensible statements about the topic. Here’s a very coherent, sober, and realistic blog post that essentially debunks the idea of fixed-bid agile while providing some very real insight into what is and is not possible.
There is a lot of great stuff in this discussion of fixed-bid agile from codesqueeze, and I especially like their use of the word ‘target’ instead of ‘fixed’. This is more than a semantic nuance – helping a client to stay within their target budget is simply good business and isn’t misleading in any way.
My favorite insights come from veteran agile expert Martin Fowler, who weighed in on the issue way back in 2003 with this refreshing explanation of why fixed price agile can work but only if the scope if also fixed, which lessens the value of the whole concept. Fowler later added this opinion on scope fixing, which further diminished the value of the whole fixed bid agile concept, then summed it all up with this:
These are the reasons why I think fixed scope
and price contracts are bad for the customer.
It’s why we at ThoughtWorks avoid this model
as much as we can. It is possible to do a fixed
price contract in an agile manner, but it’s not
wise to fix the scope.
So there it is: it’s possible to do a fixed bid project in an ‘agile manner’ by incorporating some elements of agile, but it’s not really fixed bid unless you fix the scope, and fixing the scope is just a bad idea for the client.
Sorry to disappoint, but I don’t have a clever way of making fixed price agile work. But, there is a solution for clients who want to take advantage of agile while managing costs and it starts by giving up on the fixed-bid agile concept completely.
Instead, find a development partner who can provide strong management and consultation along with great developers, and engage them to help you stay within your budget constraint. This is surprisingly easy to do – any skilled technical project manager should be able to adjust the project for risk/budget at each iteration and ensure that the budget isn’t blown, so long as the scope remains flexible.
No, you won’t have a guarantee of what you’ll get, how much you’ll pay, and when you’ll get it, but those old fashioned waterfall engagements never really delivered that anyways. And with a little discipline and reliable information from your developers, you can do a better job managing budget and timeframe than the old waterfall technique ever did.
Whatever you do, don’t get drawn in by the promise of fixed price agile – that’s for suckers.
Latest posts by Dave Hecker (see all)
- Empowering Developers: The Software Estimation Hotseat - April 18, 2017
- Impressions from Lviv IT Arena 2016 - October 11, 2016
- Contracts with Russian Teams: Interview with Gene Taschkinov - September 30, 2016