Yep - the hilarious thing is even the most Agile/Sprint heavy consulting companies usually have to succumb to some Waterfall concept in order to provide an estimate or meet a fixed bid.
Why do people ask for estimates or fixed bids? It's to manage risk. And how often do projects not go over estimated budget? Even fixed bids are poor at managing risk. Lots of consulting companies will walk away from a fixed bid contract after months of work at the point they realize they will lose money on it. And honestly, what's the quality of work once the contract is no longer profitable? We've all seen it. Everything is a quick hack at that point in a desperate effort to achieve the minimum that could be defensible in court. A fixed bid project means the consulting company and the client have opposing interests: the consulting company wants to get it done as cheaply as possible and will make every shortcut they can get away with. And the client wants every last bit of quality they can squeeze out of the contract for that price. No wonder it so often ends in dissatisfaction for both sides.
What are the options for the client when the consultant says "sorry we didn't actually finish and we are out of money"? They either pay more or have to be willing to sue the consulting company. Most companies suck it up and pay more. This is so endemic to the industry that most companies put extra in the budget for software project overruns no matter how tight the fixed bid contract is.
So one way to sell agile is to help clients understand how it can help manage risk better than a fixed bid contract or always inaccurate estimates. And how it can be used so that the interests of the consulting company and the client are better aligned.
I talked to a consulting company once that offered me a fixed price per sprint, with no commitments on how many sprints the project would take. I did not feel like our interests were any better aligned than in a fixed bid contract.
So one data point. Sounds like they didn't differentiate themselves well enough from the fixed bid contract. The great thing about fixed price per sprint is they have to impress you with progress every sprint or they risk losing the job. That's great at motivating them to deliver value to you every sprint. Another way your interests are aligned: you know how many sprints you want to pay for. That motivates you to prioritize the most important features so they are completed before you run out of budget and sprints. What a great way to manage risk.
> But lack of alignment is known to be an issue with both flat AND time-based fees.
Agreed. Agile only puts you in a more flexible relationship. It does not fix every alignment issue. For that you need to be more creative with the contract. However it does spread the risk more evenly. And by you as the client taking on more of the risk instead of pretending an estimate or contract erased it, you will do a better job of managing the risk. Every sprint you'll decide what must be built next. Every sprint you get the opportunity to change requirements. Both of those are far better ways of managing risk than fixed price contracts or estimates.
> Charging per sprint is only superficially different from charging hourly/per day/per week/biweekly.
Not if you are delivering a working product at the end of each sprint. And yes, milestones are somewhat similar to sprints. Except as a client you've now locked yourself into what gets built and if requirements change you've got to renegotiate the contract.
> You can prioritize features? But why wouldn't you do that without sprints?
Because your fixed price contract legally "guarantees" all the listed features will be included.
> Clients will want it to be over as fast as possible.
And you can have that if each sprint ends with a working product. Up to you when the product has enough features included that you are happy with it. Or that you are out of budget. And you've managed risk aligned with the consultant instead of getting an unrealistic estimate they won't meet, or having a to head to court with a broken contract.
Why do people ask for estimates or fixed bids? It's to manage risk. And how often do projects not go over estimated budget? Even fixed bids are poor at managing risk. Lots of consulting companies will walk away from a fixed bid contract after months of work at the point they realize they will lose money on it. And honestly, what's the quality of work once the contract is no longer profitable? We've all seen it. Everything is a quick hack at that point in a desperate effort to achieve the minimum that could be defensible in court. A fixed bid project means the consulting company and the client have opposing interests: the consulting company wants to get it done as cheaply as possible and will make every shortcut they can get away with. And the client wants every last bit of quality they can squeeze out of the contract for that price. No wonder it so often ends in dissatisfaction for both sides.
What are the options for the client when the consultant says "sorry we didn't actually finish and we are out of money"? They either pay more or have to be willing to sue the consulting company. Most companies suck it up and pay more. This is so endemic to the industry that most companies put extra in the budget for software project overruns no matter how tight the fixed bid contract is.
So one way to sell agile is to help clients understand how it can help manage risk better than a fixed bid contract or always inaccurate estimates. And how it can be used so that the interests of the consulting company and the client are better aligned.