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.
–
Wayne
http://www.rubykoolaid.com
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
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
On Jun 27, 2007, at 1:18 PM, Patrick A. wrote:
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 A.'s Freelancing on Rail podcast
(http://www.craigambrose.com/podcasts) helpful.
-Rob
Rob B. http://agileconsultingllc.com
[email protected]
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.
–
John Frenette
http://www.linkedin.com/in/johnfrenette
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.
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
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
On Jun 27, 2007, at 11:21 PM, Patrick A. wrote:
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 B. http://agileconsultingllc.com
[email protected]