Agile Methods != Agility
FleetingA kind of fallacy when someone claims that agile methods are about continuous improvement, adapting to constant incoming changes, while recognizing that there is a agile manifesto.
To me, you don’t need to be an expert to read the manifesto and realize it is about way more than that.
I think this is a variant of the being superman fallacy.
For instance, let’s consider this one:
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I have a hard time understanding how the face-to-face conversation is showing some adaptation to change1.
Then, some people claim that following the agile state of mind means to avoid applying rules that would clearly hurt the final objective of the team. To me, that is not following the agile state of mind, but rather common sense. You don’t have to define a method to realize that doing stuff not aligned with your engagements what be a bad idea. This applies in all domains and all situations. Agile method fortunately is more than such obvious claim.
Some might say that we have to see beyond the text and see the spirit and the idea of some authors. Seeing beyond the text and find some spiritual lead in some personal interpretation is to me religious thinking, and just avoids the debate about what agility might mean.
Either we agree that there are some concrete stuff to read to understand what agile methods are, and so far the manifesto appeared to be the perfect candidate. Or there is not, and then agile means whatever you want, making the discussion pretty useless in term of understanding what agile means.
Notes linking here
Permalink
-
Actually, sometimes, people use some agile principles in order not to adapt to change. For instance, the individuals and interactions over processes and tools fallacy might happen when people refuse to decide rules that could improve their day to day working environment (like daily meetings). ↩︎