Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
Gerhard Fiedler wrote:
>> 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.
I think of it more in terms of "natural laws", like the law of gravity. Or
more trivial: if I do A, B happens (if you step on my toe, I will scream in
I'm sure you have your own set of principles that you follow, "because they
If a procedure places more value on documentation than on working code, I
will scrap it -- because it contradicts a principle which I consider sound.
How is it a waste of resources? Why?
> "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.)
Every iteration starts with a meeting where the product owner (usually, the
customer) is asked to identify the priorities. That's your focus.
> "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.
I asked you to be specific, remember? :)
> 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...)
Give me some real world examples. By the way, I can't speak for the authors
of the manifesto, but I read "business people" to mean "customers" in
general: scientists, FBI agents, etc.
I read somewhere that Sony's engineering is based on self-organizing teams.
The engineers pick the teams they want to work on, make arrangements with
their manager-to-be, and only then tell their current manager. They also
don't hire students based on their GPA, but based on their interests and
non-academic accomplishments, especially projects they did outside of
school. So this principle is applicable to big organizations.
Sure, there are challenges and managers can't always pick the people for
their team. That's too bad, but it doesn't make the principle any less
> Which may include a good dose of
> supervision (as opposed to trust).
Never worked for me in my entire career as a manager. Did it ever work for
Eventually, I realized that whenever I lose trust in a person, it's time for
us to go our separate ways. Over time, we ended up with a team of highly
motivated, trustworthy individuals. I don't have to worry about employees
slacking off when I'm not there.
> "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.
Your statement does not invalidate the principle. It may not be possible for
you to have a face-to-face conversation, but it still is the most efficient
and effective method of conveying information. It is something to strive
> "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.)
I think you "misunderstand" on purpose. :) Working software is the only
thing that has business value. There is no business value in documentation
> "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.
I can see how it can be misread. I can paraphrase it as:
"Agile processes *are supposed to* promote sustainable development"
This usually means a reasonable work schedule, without back-to-back
marathons. It keeps people from burning out.
> "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.
As long as you could maintain this pace (frantic development/rest)
indefinitely (e.g., without burning out), and other people are OK with it,
> "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 amount of time is limited, do only what's important."
> "The best architectures, requirements, and designs emerge from
> self-organizing teams."
> 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?
There are more of them, than of you. :) The authors made the observation
(based on their experience) that people do better work when they are allowed
to organize themselves, and pick their own leaders (instead of having
leaders imposed on them).
Do you not do a "post mortem" after a project is done, or at least reflect
on what when well, and what did not?
This just says that this is a good practice, and that it needs to be done
throughout the project, not at the end of it (which is often too late).
"Documentation Options" is in the context of "Communication Options" (the
title of the chart).
"As the richness of your communication channel cools you lose physical
proximity and the conscious and subconscious clues that such proximity
provides. You also lose the benefit of multiple modalities, the ability to
communicate through techniques other than words such as gestures and facial
expressions. The ability to change vocal inflection and timing is also
lost, people not only communicate via the words they say but how they say
those words. Cockburn points out that a speaker may emphasize what they are
saying, thus changing the way they are communicating, by speeding up,
slowing down, pausing, or changing tones. Finally, the ability to answer
questions in real time, the point that distinguishes the modeling options
curve from the documentation options curve, are important because questions
provide insight into how well the information is being understood by the
>>> 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.
Go back and count how many times you used the word "Agile". :) "Redefining
what was done before the Agile Manifesto as Agile doesn't help anybody.",
etc (as if Agile claims to redefine something that was done before).
Although Rolf is of course more guilty of propagating the myths.
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