Agile programming (was Re: [P|C] Banksel)
Gerhard Fiedler email (remove spam text)
Nothing. I'm agreeing with (and expanding on) what Rolf wrote. Is this
an attack on anything? Didn't you start all this because (and this is
again quoting from memory) you wanted to hear what we think is
important? Here you have (some of) it. I happen to think that this is
more important than to know whether or not a given technique is
> Do you expect me to argue that with Agile, you don't need to pay
> attention to conditions and results?
No. What makes you think I would?
> You build strawmen, and force me to explain every time, what Agile is
This is not about Agile. This is about the above affirmation from Rolf.
> For example, your statement above implies that Agile prohibits one
> from using "unrecognized techniques".
This is not about Agile, it's about what people wrote. You wrote earlier
in this thread: "Agile does not preclude one from using any tools or
techniques, as long as they don't contradict the principles." This is
pretty much synonymous with "Agile precludes the use of tools or
techniques that contradict the principles."
As I wrote before, when I think a tool or technique is useful in a given
situation, I couldn't care less whether "Agile" (whoever or whatever
that is) "precludes" that or not. I'll use it.
Again, I'm generally not writing about Agile (or what I think it is).
I'm writing about what people write here in this discussion.
>> Right... a context and limits.
> Fine, give me some contexts/limits where the values from the Agile
> Manifesto would not be applicable.
"Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software."
There are cases where IMO "early delivery" and "valuable software" don't
go together, meaning that whatever software you will be delivering early
is not valuable and a waste of resources. (Note that I'm not saying that
this is generally wrong, just that this rule has limits and needs a
"Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage."
There are projects where limiting the change of requirements is
important. Sometimes the project manager needs to help the customer to
focus, or else the product never becomes ready -- and there's no
competitive advantage in that. (Note that I'm not saying that this is
generally wrong, just that this rule has limits and needs a context.)
"Business people and developers must work together daily throughout the
A good thing, but only in certain contexts. There are situations and
environments where this would be highly inefficient. Also, not all
programming projects are in the business domain; maybe not even most. I
would also claim that there are projects where it is helpful for the
progress of the project if business people are kept away as much as
possible. (No smiley here...)
"Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done."
Good thing, but the project manager doesn't always have the position to
choose the involved individuals. I'd say in most bigger projects, no one
manager has the position to choose all of them, so this rule has some
limitations. Sometimes you can't build the project around motivated
individuals; you may have to work with what you've got, and the issue
may not be how to transform John into a motivated individual (because
that may be impossible), but how to manage his limited motivation so
that it doesn't harm the progress. Which may include a good dose of
supervision (as opposed to trust).
"The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation."
This clearly needs a context. I have clients thousands of miles away,
and face-to-face conversation with them is nice, but not efficient for
most of the time (that is, when I'm here). /In this situation/ this
"rule" is obviously wrong, so there is a context missing.
"Working software is the primary measure of progress."
Didn't you say earlier that the measure of success is business value?
Working software is not necessarily business value, more working
software is not necessarily more business value. This is probably
downright wrong. (Which is not to say that working software is not /a/
measure of progress, but probably not the primary one.)
"Agile processes promote sustainable development."
This is not a rule, it is a claim. It may or may not be true; this
depends on the definition of the day of what is and what is not an
"Agile process" and on the specific situation where it is applied. It
also doesn't claim that Agile processes promote sustainable development
more than non-Agile processes, so it could even be bad (in the light of
this claim) to use Agile processes in a given situation. This needs a
/lot/ of context to be of any use.
"The sponsors, developers, and users should be able to maintain a
constant pace indefinitely."
This may suit some people, but not others. I used to work in "sprints",
followed by longer periods of, so-to-speak, non-commercial activities. I
liked that better at the time. I don't know why I should have done this
differently, just because the Agile Manifesto says so.
"Simplicity--the art of maximizing the amount of work not done--is
It seems to me that this is not meant in the way Wally (of Dilbert)
would understand it, so it definitely needs some context.
"The best architectures, requirements, and designs emerge from
This is a rather broad claim, and I don't see how they could
substantiate it. Anybody can claim something like this, but that doesn't
make it true. By the same token, I could claim that the best
architectures, requirements, and designs emerge from teams with good
leadership. Now what?
"At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly."
While this would be nice, reality is that there are always some humans
on the teams -- at least that's my experience. And among humans it seems
to be common to have difficulties to adjust certain behavior traits in a
timeframe relevant for a programming project. So just a word of caution:
this may not be achievable when working with humans, so there is
definitely a context missing here.
In general, I think there are situations where this collection applies
rather well, but there are also many situations where it doesn't. So
knowing the (not stated) limitations and the (not stated) context is
quite important when applying the techniques that are based on these
principles, rules and claims.
>> For example, you posted a link earlier about documentation. This guy
>> had a diagram in his page, where both richness and efficiency of
>> documentation increases from paper over audio to video. Utter BS,
>> this diagram, if you start to analyze it.
> I can't find the document you are referring to, but I'm pretty sure I
> know which diagram you're talking about, and I think you
> misunderstood what it was showing. The diagram was grading the
> efficiency of the forms of _communication_, not _documentation_.
Look at the diagram again, and tell me how "Documentation Options" is
not about documentation (the author says that these are the "options for
when you are documenting"). As I wrote before, I commented on the graph
"Documentation Options", not the graph "Modeling Options". Maybe read my
earlier comments again, now with the graph in front of you. (And note
that I'm not talking about the relative position of the documentation
dots on the "richness" scale, but on the "effectiveness" scale.)
I was wrong about he not including electronic media; in the text he
writes "paper includes electronic media such as HTML that could be
rendered to paper". To me this is not any less strange than leaving it
out. Electronic documentation, for me at least, is much more effective
than paper documentation: it's searchable. Whoever hasn't understood the
importance (and effectiveness) of being able to (electronically) search
documentation IMO didn't understand much of what documentation is about.
Which kind of reflects on everything else he says about it. And placing
electronic (searchable) documentation at the same effectiveness spot as
paper documentation shows a clear lack of understanding of this crucial
>> In this thread, I commented almost exclusively on your comments
>> (which includes what you say that Agile is for you), not about Agile
>> in itself. I don't make judgments about Agile, but comment on
>> specific affirmations, independently of where they come from.
> That's not true. You keep making statements about the vision of Agile
> that you have created.
> You also said at one point, that the points in Agile manifesto
> contradict themselves. I'm still waiting for you to identify the
> specific points in question, and explain that statement.
You never asked me before. In this message you asked me, and you got it.
>> (Like you said that the Manifesto changed the management world,
> When did I say this?!!
"Agile addresses two big fallacies with project management: (1) men and
months are interchangeable and (2) requirements never change."
Not exactly the same, so I slightly misquoted out of memory. But in
essence, this is what you wrote; addressing two big fallacies with
project management results in changing the management world.
Not sure what you wanted to write here (it seems unfinished), but I hope
you are aware that (IMO) Rolf wrote this kind of tongue-in-cheek, and so
did I. Responding to a similar paragraph of yours (which I snipped).
In reply to: <22251822E9BA47B2846176480D30BEEC@ws11>
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