Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
Gerhard Fiedler 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
Gerhard, please don't get me wrong, and don't take offense at what I say. I
think that you really should learn more about Agile, because your statement
reveals your ignorance about the way it really works. The problem of getting
the customer's buy-in has been addressed numerous times, to the point where
it became an almost cookbook solution.
Fixed-Price contracts in an agile organization
(sort of an FAQ):
Selling Agile (you can skip to page 14)
Contracting Agile Projects
While customers find comfort in fixed price (meaning fixed price, scope, and
timeline) agreements, you know that you are lying when you're giving the
estimate to the customer, because you have no idea what the project will
Lean Development & the Predictability Paradox
I've been on the customer end, and I understand why customers prefer fixed
price deals. I also know that most consultants/contractors want to charge on
the per hour basis (some people we requested quotes from, refused to sign
the NDA as soon as they heard that the fixed price requirement is
> 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?
"Working software" means software that has been tested and debugged, and
that does something useful. This is in contrast with the traditional method,
where the software (almost by definition) is basically broken for most of
its lifetime, until the integration and testing phases are complete.
> 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... :)
You pretty much answered your own question. You described how an agile team
would approach this. :)
Of course, you have requirements for the project, in the form of the project
backlog. The tasks (features) on this project backlog come from the
customer. In practice, you can have stickie notes, one per task. The
customer then tells the developers which tasks are the most important. The
programmers pick enough tasks off the top of the backlog for one iteration
(aka "sprint"), write more detailed requirements if necessary, and start
At the end of the sprint, the programmers end up with working software. It
is presented to the customer, the customer provides feedback, together they
look at the tasks, add new ones/reprioritize the backlog, and the process is
Here are some benefits of this method, compared to the traditional
1. At the end of each sprint, the customer gets working software. It may
even be useful enough to be deployed, even before the remaining features are
2. As the development progresses, the customer can eliminate some features
based on the changing external factors, or the feedback they get from using
the software. With traditional approach, this would require contract
negotiation, so what you get in the end, is a product that has features that
no one uses.
3. At any point, the customer may decide they have enough useful
functionality, and terminate the project. In traditional environment, they
may end up with nothing but broken code, and heaps of paperwork (and
perhaps, a lawsuit).
> 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.
As I explained earlier, neither I nor the original signatories claim that
the principles are new.
> They are a collection of some common sense principles
> and unproven (and unprovable) axioms, nicely worded.
Which ones do you have in mind?
> 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.
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