Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
Nate Duehr wrote:
>> Did you catch this -- "Customer collaboration over contract
> As a non-programmer, but someone who's been involved in business
> purchase decisions, this seems to be Agile's achilles heel.
Glad you decided to join the conversation.
> Customers want to know what they're entitled to before they pay. If
> they start paying a company that's "Agile" to "collaborate" and the
> collaboration slows down or becomes bogged down in some set of
> details, what recourse do they have? In the more traditional RFP/
> Requirements/Then Build environment, if the software doesn't meet the
> requirements, they have legal recourse to sue.
This is a valid concern, but one that has been addressed. I posted links to
three documents that describe in detail, how it works. See for example:
Contracting Agile Projects
Lawsuits are expensive, and the customer must prove in the court of law,
that the company is in breach of contract.
Agile promotes customer collaboration, which helps avoid lawsuits.
Everything is transparent, at the end of each iteration the customer can see
for himself what has been done.
In the more traditional environment you alluded to, they get assurances in
the form of progress reports. Lawsuits happen when the customer feels he has
been lied to. Working code does not lie.
> If you've convinced them that they can just "collaborate" with your
> team, and then say -- decide you want to downsize the team
> (effectively making delivery dates stretch out longer), what can they
> do about it if they've been paying and collaborating all along.
They can walk away as soon as they feel they're not getting the results they
want, at a reasonable pace. Every iteration is only a couple of weeks long,
and the customer gets working software at the end of each one.
> Agile seems to be idealistic about software relationships between
> companies being a "forever" thing.
This couldn't be farther from the truth. In fact, because the customer gets
working software at the end of each iteration, they can theoretically decide
in the middle of the project that they have enough functionality, and
terminate the project. Try doing that with a traditional project, and you
will end up with a bunch of untested code, or worse.
> Additionally, how do you handle it when one customer wants to
> completely change what the software does or how to interact with it,
> and the majority of customers want it another way? Agile never
> addresses that. They assume "all customers are equal". We all know
> they're not. Change this example to "your largest customer who brings
> in 25% of your revenue" and it starts to become very difficult to
> smash Agile development up against the cold reality of customer wants/
> desires, doesn't it?
Another straw man. :)
Now, why would you say that "Agile assumes that all customers are equal"? Is
this something you read in the Agile Manifesto? Or maybe, it's one of the
agile principles? :)
Agile teams have a concept of "Product Owner". The job of the Product Owner
is to act as a liason between the customers and the team, and to represent
the interests of the customers on a day-to-day basis.
This also goes back to "customer collaboration": in order for the agile
process to work, customer must be a part of this process. That's what the
sprint meetings are for -- once every iteration, the customer gets working
software, and is expected to provide feedback to the team, and help
prioritize the task list for the next sprint.
> Maybe someone on an Agile team that has lots of customers can
> explain. Do you just end up having to sales-pitch the smaller
> customers into liking what the largest "collaborators" want?
We rarely work with outside customers on software projects, so I probably
don't have enough credibility to really answer your question. I do assume
the role of product owner from time to time, as do other developers, and
AFAIK what I described above is considered standard practice.
The bottom line is, business relationships, like any other form of
relationships, are based on mutual benefit. When one company contracts
another company to develop software, they are both interested in a
successful outcome. So to me, it makes sense to put the bulk of the effort
into making sure the project succeeds, rather than on negotiating a
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the