Vitaliy wrote: > "Gerhard Fiedler" wrote: >>>> "Every project is different. What works for one project may not >>>> work for another project. What doesn't work for one project may >>>> work for another project. There are no rules, you must adapt." >> >> This is a good rule. It means we need to pay attention, even when >> using Agile-approved methods. It means we need to pay attention to >> the conditions and results. It means we need to pay attention where >> we start making compromises, not because something better suited >> would not be available, but because what's available is not a >> "recognized technique" by whatever authority. > > What are you attacking with this, Gerhard? 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 Agile-compliant. > 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 > not. 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 context.) "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 project." 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 essential." 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 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? "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 feature. >> 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. Where? > 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. >>> For the record, I live in Canada. It is great, and is good for >>> everyone. If where you are works for you -- there's no reason to >>> change if you are happy where you are. If, on the other hand, you >>> are dissatisfied with the status quo (like I was before I came to >>> Canada), I would encourage you to emigrate. New places, especially >>> ones that have a catchy name that begins with a capital letter, >>> usually meet with resistance -- it is to be expected. >> >> Ah, and Brazil... ever thought about moving here? :) > > Why don't you 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). Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist