piclist 2009\01\31\081221a >
Thread: Agile programming (was Re: [P|C] Banksel)
www.piclist.com/techref/microchip/devprogs.htm?key=programming
picon face BY : Gerhard Fiedler email (remove spam text)



Vitaliy wrote:

> The benefits to the customer are legion. IMHO you just need to
> understand them yourself, and be able to articulate them to get the
> customer's buy-in.

I'd like to see you selling programming services to customers, saying
something like: "In a month we expect you to give us $50k for the work
done up to then. At that point you will get something that 'works'. It
will do 'something', but what it is that it will do I can't disclose or
define up front, as this would be against our methodology. We will
listen to all your input, and I assure you that we will do our best to
consider it. Now trust me and sign here at the dotted line, please."

Come on... this works in situations where the customer hires per hour,
trusts the programmers (and their managers), and is willing to pay for
whatever he gets, trusting that it will be as much as possible in
alignment with what he wants. Which is a possible scenario, but not very
common.

A more common scenario is a fixed price deal. In a fixed price deal, you
can of course work inside the deal with Agile, but you can't really let
the customer dictate the outcome as you go. Ever heard of featuritis? If
you don't put contractual breaks on the cart, the customer will usually
want more. You show him one prototype, he'll think of a dozen additional
things he'd like to see. You show him the next prototype (that features
a first draft of five of them), and boom -- there is another dozen new
features he'd like to have and hasn't thought of before. You see where
this goes without contractual definitions of what it is that you have to
deliver to get your money. You won't ever get your money if you don't
limit the deliverable -- which is a requirements document that defines
the deliverable.

The contractual conversations are quite often about finding the right
balance between what to do and what to pay. Many clients want to know up
front what they will get for their money -- and there you have the
requirements. Also, often there is the case that if they can't get to
point X with their budget, it doesn't make sense to start at all, so
they have to make sure that they can get at least to point X if they
don't want to waste money. Which has a definition, aka requirements.

There is/was another thread where we talked about incentives and how
important they are for the outcome. The programmers need to have an
incentive to get where the customer wants to go. One of the most common
incentives is payment. If this is not linked to some definition of the
desired result, it can become a very weak incentive. "Trust them to get
the job done"... hm. Can work, but can also go (expensively) wrong,
especially if it's not you who is hiring and managing (motivating) them.

There is also the idea of "working software", mentioned several times in
the Agile Manifesto. What does "working" mean? There needs to be some
definition, right? Wouldn't that be a requirement? And wouldn't it have
to be established up front? (With "up front" I don't necessarily mean
"fixed at the beginning of everything", but "at the beginning of an
iteration". If what "working" means is not at all clear at the beginning
of an iteration, I doubt that the iteration will be all-around called a
success. Which then is suspiciously close to a milestone... :)

Don't get me wrong... I don't think the principles of the Agile
Manifesto are wrong. But they are not /everything/ -- and they are not
that new. Maybe they were in certain circles before 2001, but they
weren't in others. They are a collection of some common sense principles
and unproven (and unprovable) axioms, nicely worded. It also seems to me
that it is targeted at a specific subset of programming settings; it is
easy for me to come up with situations where some of the principles
simply don't apply. Maybe the creators just didn't consider these
situations, because they were outside their target or experience. But
that doesn't make them any less real. There are also scenarios where one
principle contradicts another. So it's all not that easy.

Gerhard
<2w6kvdmm6j8u$.dlg@connectionbrazil.com> 7bit

In reply to: <7080603C73284B6D91F315CF621FBE9A@ws11>
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Agile programming (was Re: [P|C] Banksel)

month overview.

new search...