question about agile development

Hey all,
Hope this is not too offtopic.
I read everywhere that Agile development is against having a contract
with a fixed price from the beginning and that it's better to work
with the client in small iterations.
I have one question though, when do we start talking price with the
client? At the end of each iteration? At the beginning of each
iteration? Does the client have to pay me at the end of each
iteration? Or do we talk about price at the end of the project only?

Thanx in advance

Pat

I didn't think Agile was against a contract with a fixed price, but
against a flat-out "You'll do x, y and z" contract for designing the
software itself. I imagine you'd have to set up some kind of "payment
plan" with the client, either payment upon delivery of the project, or
upon delivering milestones. I think it's something that has to be
worked out with the original client, but I'm not that familiar with
Agile stuff to be 100% sure.

The main thing with Agile development is that you do not know what you are building until you get there.

That requires a very trusting client. Time and Materials or payment per iteration is a good way to go in most cases.

If you have a client that is very risk adverse and you are willing to assume the risk you can make a better rate for absorbing the risk, assuming you can do a good up-front estimate for something you do not yet understand fully. If the client is going to look at the work done and in their head compute your hourly rate back again, it is hard to make this a win-win situation. Either you end up doing too much work, or the customer can end up feeling taken. The thing to emphasize is that they were paying for insurance. They paid a premium for the certainty of what it would cost. The only way I will do a fixed-price project is to get the client to answer the question "what is this worth to you", rather than doing time estimates and big project specs. The risk of an offended client, or eating peanut butter for weeks are too high when the fixed price is based on up front project plans.

Michael

Hey all,
Hope this is not too offtopic.
I read everywhere that Agile development is against having a contract
with a fixed price from the beginning and that it's better to work
with the client in small iterations.

The problem with "fixed price" is that the scope of a project is rarely so well-defined that such a price can be reasonably determined. The client wants to get as much as possible for the money they've agreed to spend, while the developer wants to minimize the total effort to deliver the project.

I have one question though, when do we start talking price with the
client?

VERY early in the process. You might need to have a non-billable discussion of the total project and what the initial deliverable will be before you can even start discussing price.

At the end of each iteration?

Well, you want to make sure that the delivered functionality is acceptable...

At the beginning of each iteration?

... based on the scope and estimated effort agreed to at the start of the iteration.

Does the client have to pay me at the end of each iteration? Or do we talk about price at the end of the project only?

How you're paid and the timing of payments is somewhat independent of the rate/price, but I'd suggest having a regular invoice cycle (per iteration). The idea with an agile methodology is that after just a couple iterations, the client should be able to accurately gauge the value receive for his/her money with each new iteration and thus be empowered to make the decision whether to stop ("the project is now good enough" or "that's all I can spend right now") or continue with another iteration ("that's great, but now let's add ..."). You should be adding value with each iteration and that's when you should be paid.

Thanx in advance

Pat

You might find the Craig Ambrose's Freelancing on Rail podcast (http://www.craigambrose.com/podcasts) helpful.

-Rob

Rob Biedenharn http://agileconsultingllc.com
Rob@AgileConsultingLLC.com

ok thanx a lot for all your really good answers.

To sum it up, the client gets an idea of how much value he’s getting per iteration after a couple of iterations. I get paid at the end of each iteration and the price should be discussed before the start of each iteration which is a mini project in itself or rather a mini milestonee so I can propose a price before the start of iterations, I need to evaluate how much work each iteration is going to be. Is that it?

thanx in advance

Pat

One difference in Agile development, velocity is more important than momentum. In other words what you have done at the end of an iteration is less important than the amount of work done in the iteration. THe idea is to embrace and expect change in what gets done as the project unfolds. That is what can be tricky with a cast in stone fixed price contract, even for a 2 week iteration. If you are not being paid for effort, you end up with a hybrid approach rather than pure Agile. And, for many clients that will be just fine.

Michael

Or do we talk about price at the end of the project only?

I just wanted to interject a little input on clients and billing here: unless you have a rock-solid, blood-oath, pinky-swear relationship with all your clients, waiting until the end to talk price will frequently get you burned and underpaid (or unpaid) with many people out there that would be soliciting your services. I think defining expectations on both ends and being as clear as humanly possible throughout the whole contracting/billing process really helps manage expectations on both sides, and is more apt to leave both parties satisfied with the value of the work being done.

Also: the traditional Waterfall method is hard enough for the average client to grasp–frequently I have seen clients assume that features and functionality will be part of a finished product, even when it was never defined in the agreed upon spec; going with an Agile methodology can be even tougher for regular joes to understand and embrace. If your client is familiar with Agile development or has experience from previous projects, great; but I think explaining your methods and communicating your intentions and expectations (and having them communicate theirs) will go a long way in making you both happy.

Also there are practical issues. I offered a client a sweet deal. A fixed price and it was done when they used it in production. Very slanted in their direction, because they were gun shy from a prior project by someone else, and I knew them well enough to take the risk. Even with all that, the lawyers insisted on a definition of what would be delivered so the contract could have defined consideration from both parties. They defined what they would pay, and we needed to define what I was delivering beyond “good software”. So, no matter how forward thinking a client is, the business reality is going to drive a certain amount of preplanning. True Agile development really is oriented to in-house development or hourly consulting. Any other payment terms create a hybrid approach.

Michael

so when dealing with a client in real life, we still have to define a price before each iteration which implies that applying agile in real life when not in-house is impossible? as not having a fixed-price is one of the most important thing in agile (because it allows flexibility etc) and if we don’t have that do we still have agile? because even if we can work in small iterations and all that, if we have a fixed-price before each iteration then we still can get screwed.

You can have a fixed RATE and that can be for an iteration rather than an hour. The key is that you are negotiating SCOPE and EFFORT for the iteration. The client lays out the features (“stories” if you’re XP) to be considered for the next iteration, you attach an effort estimate to each feature, the total effort available during the next iteration is “fixed” (typically, your accuracy on this effort amount goes up as you get some experience with the client, project, and your own ability), and the client picks the set of features so that the sum of the effort fits into the allotted limit for the iteration.

One thing some clients have a hard time understanding is that every change is “equal” – it doesn’t matter if it is a change to something delivered (correctly!) in a prior iteration, a brand-new feature, or ripping something out – each thing gets an estimate.

If done well, the client has the benefit of being able to consider the project “done” at any time. Of course, that may be one of your definitions of “getting screwed”, but so long as the client sees that value is being added to the project (and you’re satisfied with your estimated versus actual effort), you’re more likely to get to a state that both of you call “done”.

-Rob

Rob Biedenharn http://agileconsultingllc.com

Rob@AgileConsultingLLC.com

For customers willing to take it one iteration at a time, you can be pretty agile. That generally requires a fair amount of trust on their part. Most clients want to know how much the whole project will be (at least a ballpark estimate). That can be a problem. The whole point of Agile is to not pre-plan the entire project, but to adjust things as you go.

But, theory aside, every client has different concerns, different fears, different expectations. You need to talk and listen to them to negotiate a project plan and payment plan that work for both of you.

Michael