I hear very positive things about Agile Development, in particular as a way to keep the customer involved throughout the process, and therefore maximising the likelihood of building what the customer actually needs.
The issue I have is the vast majority of new/potential customers want fixed quotes which to my mind forces us down the predictive rather than adaptive path.
What pricing structures have folk here had success with on agile projects?
If you want to work in agile mode, there is no point in discussing fixed prices. People don't understand that. To give a fixed price, you need to understand the requirements in detail up front. And if you do that you are not agile. These two things are opposite. Plus, if you give a fixed cost, you can't afford to have requirements change as you are developing (another thing that is not agile).
Having said that, the customer must budget, so you do have to understand where they are coming from.
All our agile projects run on Time and Material costing.
Hmm, this is an interesting question.
I think the best way to go about this would be to price based on the user story. Plan out an eagle eye list of features and price based on those features. Make it clear that if there is scope creep the fixed price will change. You need to be realistic when pricing though, which makes it difficult to not plan everything down to the day/hour. However, I think you can generally figure out how long something will take and price based on that.
I have found that Agile makes it easy to be transparent, and the client will likely appreciate that.
I don't think that Agile really works with a fixed-price model. I can't see it working outside of time & materials.
I've worked on several fixed price agile projects - My advice is simply don't.
About the only option you have is to timebox certain tasks - i.e. we're going to work in iterations, the system will always be 'working, but our quote is for a maximum of X days total (or A on feature a, B on feature B etc). That requires a high degree of trust be developed that you're not padding time logs, and unfortunately always leads to customer disappointment unless they have budget to buy more time on the features they discover they care about.
I'm working in a web development company, where clients often come with an idea that they need "super cool new web site", which is of course something that is going to swing back and forth throughout the project. Basically, standard path is mixed approach: first there is set of fixed functionality with fixed price. All those functionality are built iteratively, so client will have chance to give an opinion. Whatever something is requested that is out of the original scope, it is left for after the original project is finished, and usually carried out through some sort of support/maintenance agreement, which would be there anyway, so you increase price a bit, but for a long period of time. If client really insists, contract and price could be modified to include new stuff immediately.
I guess most critical part is understanding client's needs and offering right solutions in the start, which is not all that agile.
@Brian,
That triangle makes sense. We generally won't compromise too much on quality, so delay is the most common risk. Debates over what's in/out of scope exacerbate that. I do like the idea of using it as a tool for identifying which is priority for a customer.
@Sara,
That's actually pretty close to what we currently do. We also try to highlight as optional extras items we can foresee being asked for and being expensive to implement. But yes, by the time we've done that we've created a pretty detailed plan.
Being in the software development industry has one big downside: there's a big group of clients who simply don't understand the complexity of their requirements. Going for an agile approach if your client doesn't think what you're doing is complex is probably one of the biggest risks you can take. To minimize the risk you should always consult your client first, ask what they think is reasonable, and most importantly, be able to explain why you need so much time. Be careful with real-world analogies, as those are usually flawed in one or more aspects.
I've found that the first thing you should try to figure out is if your client is open to an agile approach. Brian already pinpointed the problem, the project triangle. The biggest problem I encounter with my projects is usually the client's approach, their mentality if you will.
I think the best solution is what Slartibartfast suggests: Find the minimum requirements, try to find the the minimum and maximum time required and try to establish a fixed price somewhere in the middle. Indicate that you will make sure the system will fulfill the requirements which you put down on paper, and make sure you both agree on them. Tell your client that for complex requirements you want to use an agile approach, which in layman's terms means that you will build small parts and then consult them, with the price simply being in the hours (and materials) you invest (with an appropriate margin for you to make profit of course ;)).
If your client will not agree with that, you could always reject the project. You shouldn't take on every project that's offered to you, especially not the ones that have a big risk of forcing you to either deliver a sub-par product (to your standards) or run out of budget.
It's better to not do a project than to do a project below your standards, as it might hurt your good name.
That being said, I'm still looking for a way to make the business people understand my point of view, so good luck on this one ;-)
Thanks all. So from everyone's advice...
I'm currently thinking Specs where I have to provide a fixed quote.
And then I really like the the idea of using Agile/T&M for add-ons to a project. By nature I think our quoting is weakest when we have to do it mid-project, so that would help manage what's probably our biggest risk area.