Re: test-driven iterative user centered design
- --- In email@example.com, "Desilets, Alain"
>I don't find that there is a lack of trust based on what you have
>> Actually, that's roughly the approach we use and it is the best I've
>> ever used for all involved. "Fixed price, variable scope". That gives
>> everyone who wants to know the budget a number and we virtually always
>> deliver on budget. That makes people happy and life easier for all
> -- Alain:
> Do you find there are problems of trust at sales time or during the
> project? In other words, do you find your clients are afraid that you
> will slack off (since payment is not tied to delivery of a final
> The one time I negociated a fixed price, variable scope contract, I
> found I could easily address that fear by explaining the transparency of
> XP to the client, i.e. things like:
> - single bull-pen area for the whole project team
> - possibility for the client to have a representative in that bull-pen
> area at all time (actually, this is not only possible, but highly
> - weekly or semi-weekly delivery of working prototypes
said. I've got three kinds of clients...
a) Those I've done work for before. For those people, it is all about
what they have the budget to do. They seem to believe we will deliver
(based on past experience) and that the process will keep us on track
for at least some of the reasons you mentioned.
b) Those I haven't done work for before and who found me because they
were looking for someone to outsource to who would do agile
development or, more specifically XP. For these people, the big issue
is both budget and the idea of trying to figure out what they'll have
at the end of the budget... "Let's see, if I can get a budget for 6
iterations and we get something that roughly delivers the stories
we've got laid out, will I get in trouble for not having more stories
done for that budget or will I have trouble getting the next chunk of
budget we'll need to get the next stories people will want."
c) Those I haven't done work for before and who don't know anything
about XP or agile. These people are all over the map. They almost
never expect XP or the implications of it. So, we spend a lot of time
trying to convince them that this is either a good or the best way of
approaching there project and, if they buy the general idea, trying to
help them figure out how to get the people they need on the business
side to devote the time they'll need (and of course, the budget). Of
course, we are also competing against whatever other alternatives they
think they have (which runs the gamut from big players, small local
players, internal players, buy vs. build, etc.). One of their
objections MAY be what you mentioned, but I've found that people with
that objection usually have a lot of other issues with respect to
preparedness or accepting reality that are much bigger issues and this
objection is usually just a symptom of a bigger underlying problem.
I'd rather find the bigger underlying problem earlier rather than
later. Sometimes we can help them work through it, other times they
go away. Either way, it's OK.