A reader asks about Agile vs. Fixed-Price, Fixed-Scope, Fixed-Schedule contracts:
"Is there an Agile way of figuring out how long a project will take to deliver the final product a client wants? With this, how much money it'll cost a client?
In all this, Agile seems a bit like 'We know nothing but promise to learn. We'll just start hacking and see where it ends.'
Of course the client will get EXACTLY what he wants, but I think every client would like to know up front how much time and money will be consumed."
Steve Eichert had a similar question:
"The one thing that I still have a hard time with when it comes to Agile is the whole idea of giving the customer the opportunity to cancel the project after any iteration if the project isn't proving to be of enough value. How does a small to medium size company plan for such a thing. If at the end of an iteration the customer says that's it, pack your bags we done, then what? Does the project team then get sent back to the “home office” to sit on the “bench” until another project starts up? What if there isn't work that's ready to begin when the project ends?"
To which Alistair Coburn responds:
"There's some bravado talk in this quote from agile conversations. Take out the bravado and something sensible emerges that you can use.
In house development: it quite often happens that the company runs short on funds before the project gets "completed". Normally there's a good lead time on this information, so it's not a great surprise (well, sometimes it is).
If you run your project as though it could get canceled after any iteration, then you make sure you load up on delivering good business value early, so in case they run out of money, you've delivered the most value for the money spent. If they don't run out of money, no problem. Compare this with waterfall ---- if they run out of money 1 month before the end, you're left with nothing.
Contracting situation, fixed-price, fixed-time. You do the usual thing with underbidding and get caught at the end needing more time. My friend Jeff would always make sure he loaded up on good business value along the way, so when he got caught at the end, the things they had to negotiate penalties over were obvious to everyone as being the least important. They customer often just forgave them the difference. His colleagues on the other projects, though, couldn't trim off the end that way, and simply worked massive overtime.
Finally, the bragado. So no one will contract you to do XP (e.g.). What can you do? You offer them: You retain the right to cancel the project after any iteration if you're not satisfied with our progress; we're sure that you'll be so happy with what you see showing up that you'll keep us going. That's called putting your money where your mouth is. It's also called being cocky, (over)confident, and mouthing off.
You don't have to do this to do agile, but it doesn't hurt to run the project as though it were the case."
So maybe we won't agree to let the client cancel after every iteration. On the other hand, I don't think anyone will disagree that scheduling is a concern. I touched on this subject in my Responses to Agile Concerns post:
"Technically, you cannot schedule/forecast with 100 percent certainty. The problem is that scheduling and forecasting will no longer have the “crutch” of fixed-scope fixed-length contracts. This is a standard staffing problem, and seasonal jobs offer some interesting possibilities. Another possible response is to make sure that there is sufficient work in the “hopper” so that there is always more work. And if there is a regular sizable backlog of work in the hopper, then it is time to hire more people.
Short iterations work against a lot of current management practices. For example, discounting initial work to get a customer could result in that customer getting a bunch of quality work done for cheap, and then taking their business to the next low bidder. The easiest way to avoid this is to avoid making the initial discount. I think, and a small amount of experience has proven me right so far (I am not making any definitive claims yet), is that this type of arrangement will self-select customers that want a relationship. According to Crossing the Chasm, the pragmatists want a single supplier anyway, so once you have proven you worth, they will stick around. And these are the kinds of customers with money that you want (compared to the visionaries).
Certainly there is some risk and uncertainty. I believe the risk is nullified by the elimination of fixed-price contracts that go over budget and leave the development organization eating the cost. The customer also wins by avoiding situations where the fixed-price contract covered 2 weeks worth of work that was finished in 2 days! This can go a long way toward crossing the divide between the business people and the technical people.
Also see The Predictability Paradox, by Mary Poppendieck."
The more we try to predict, the more stable requirements have to be, which is antithetical to agile development. Martin Fowler explains:
"Many people belive that you can't do a fixed price contract in an agile project. Since the whole point of an agile process is that you cannot predict the future, this isn't an unreasonable supposition. However this doesn't mean you can't come up with a fixed price agile contract, what it means is that you can't come up with a fixed price and fixed scope contract.
Usually when people say fixed price, they mean fixing price, time, and scope. This requires detailed, stable, and accurate requirements. The whole point of agile development is that it works with more fuzzy requirements. To handle this with a fixed price contract you essentially come up with a plan that says "we have $x to spend and we need a release on 1 Dec. We'll collaborate together to come up with the best set of features to go live with on that date."
The initial plan
The initial plan for this kind of arrangement is not really any different to a predictive project. The essential difference is that we don't expect things to go according to plan. Instead we expect to deliver a better product that we can currently envision, because we'll learn more about the project as the project proceeds.
Or if we find things are much tougher, we'll find that out too. In which case we'll modify the plan. If the customer doesn't like the resulting plan they can cancel. While this isn't good, they'll usually cancel earlier than they would under a predictive project, becuase predictive plans tend to discourage change, and thus make it easier to not realize when things are going off course."
With an intial plan, what we need are resources. Luckily Mary Poppendieck has a good list of Agile Contract resources. Here are some of the downloads, check out the site for more:
-
Fixed Price Contract & Agile Software Development - An Experience Report, by Christine Moore
-
The Rule of 3rds - An Agile Approach, by Christine Moore
-
Sample Language and Stories, by Cem Kaner
-
Excerpt on Contracts from Lean Software Development, by Mary Poppendieck and Tom Poppendieck
-
Sample Contract Wording (specifying a Prototype to provide learning)
-
Draft DSDM Contract, Commentary, & License, by Richard Stephens and the DSDM Consortium
-
Optional Scope Project, by Marina Morgagni – Manager, eXtreme Programming Centre & Piergiuliano Bossi – Coach, eXtreme Programming Centre, Quinary SpA, Italy (Submitted to XP2003 Workshop)
-
Pay Per Use Contracts, by Nora Sleumer, Massimo Arnoldi, Massimo Milan
Lifeware SA, Switzerland (Submitted to XP2003 Workshop)
Hopefully there is something in these resources that will help for your particular situation!