> The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace m

> The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. [...] The problem is: the manifesto states clear dichotomous preferences without nuance, and it certainly not for example states that it embraces well-maintained and useful documentation but that "[we value] working software over comprehensive documentation". See? It is written "comprehensive". Not "shitty". And I even agree that maybe "comprehensive documentation" can be a dangerous concept if taken too far, but that's pretty much true for anything taken too far, and actually I have never seen a problem in this direction, but pretty much all the time and extremely often in the opposite way (I could say : a comprehensive lack of documentation...). So maybe de-emphasizing "documentation" was not that smart... Either it was very poorly written or there is an attempt at rewriting history. At the end of the day, you can't just hand wave the shortcomings originating directly from the text by just stating "oh but we did not mean that, wasn't it obvious?" -- well... no! it was not! Likewise for the other "values". They seem to have been written because of a perceived lack of balance (and maybe there are even again some adjustments to be made and they are not exactly intended to mean what is written...) in the personal experiences of the signatories, however there is no provision against balancing too much in the other direction, or against inappropriate applications in specific contexts (the "preferred values" are actually extremely context and project dependent) So maybe people actually got what was written, or maybe the whole thing was so vague that they got random outcome from a mostly cargo cult application. And in a few case, intelligent practice in a good context, so good outcomes; but when that happens, would the successful team have done poorly with other preferences of "values" or with other stereotypical day-to-day practices (weird btw when processes are to be deemphased)? > What do you mean you’re going to start building the software before you’ve gathered all of the requirements and estimated every piece of functionality? That’s insane! Like, the significant software from the 80 or 90 was written like that (in inappropriate contexts)? And when it was (again, in inappropriate cases), was the solution to settle on the four stated value preferences? Why? From where does that even come from? Where is the evidence? How can it be applied? Why can't I write precisely the opposite and say "see? here is my solution!" -- if not just because of the obviousness of some outcome: yeah not valuing working software enough will probably not lead to better working software. My point, however, is that stating that you value working software more cannot yield to actionable things in not completely dysfunctional environment, because whatever their current practices are everybody will say they want that and what they are currently doing has value to achieve that goal. And the other value preferences are highly contextual. There is no silver bullet. Not in technical areas. Not in project management. Especially not when project management is not interested in the technic; that is: in the project, if the project is of a technical nature...