fr-agilists?
Ouch! and one month later
Ouch!(follow the links)
If you read through the posts and comments, the heart of the arguments come out. Agile methods and values are no longer the 'fair haired boys" of the industry. The early adopter phase is over and people reconciling the different views are coming to blows. I have to say that I experienced much of the zealotry of some agile evangelists while participating in the Yahoo TDD group. There is almost a religious zeal on the part of some of the practitioners, one where questioning the process puts you in the immediate line of fire.
Scott seems to be making the point that the agile techniques are too hard to explain succinctly and that only by diving in fully and experiencing the methods in person with an open mind can you be in a position to criticize. Considering all the parts, that's asking a lot of the merely curious. Odd to for an approach that values evolution over planning, don't you think? Here are some observations to throw into the fire.
- There are many who have staked their careers on big up front designs, and yes, some of them are good at it, enjoy it, and get software delivered. Agile techniques are an attack on them, often a very personal attack. Expect reaction and don't be surprised when they don't accept "you don't get it" as a justification.
- Agile techniques are presented to developers primarily. There are a lot of parts to the process and some require changes to people outside the developer community. Developers are usually not in a position to make those changes and are often not practiced at the influence skills that would make that possible.
- Could somebody quantify that pair programming is or is not a productivity loss? Account for quality gains if this can be proven. Account for the gains from shared code ownership if that can be proven. Otherwise we'll be arguing forever
- While the Agile Manifesto does provide meaningful values, it does not provide a meaningful vision of how the world looks as an agile shop to a newcomer. As you look for more clarity of that vision, you will find an incredibly confused, contradictory and sometimes hostile picture. Others would say there is a vision: pick mine.
- Tests and code as the real documentation: I have believed this to be true for many years. However this is only true for the developers. If the tests really were the expression of what the customer or business analyst expressed in a language they understood, they should own them, then you might have something. Hmmm, sounds like Domain Driven Design!
- Bob Martin seems to take particular offense to code that doesn't have automated tests and that judgment, or "calculated risk" can guide you in what to test and what not to test. What about a manual test? What about unchanged code that has been in production (and tested manually) for a long time? What about low impact code with a high probability of "just works"? Generated code with a few parameters? No shortcuts to meet a deadline?!
- I am beginning to believe that to succeed with agile techniques, you
have to buy the full deal, not just pick parts that interest you. The
parts all fit together and may not work nearly as well with any of them
missing. I used to think pair programming was optional, but as I see
things play out, I wonder if it is really the most important part of
the package. I wonder how I feel about that ;-)
Change involving groups of people is always hard and requires tremendous leadership. It requires time and patience. It requires faith. Being right or wrong is almost irrelevant once you are in the midst of the change. Being fr-agile is identical to sticking your head in the sand about the real problems at hand.
Ron Jeffries has been a master at staying in the fight to help people but keeping above the fray. The agile movement need lots more people like Ron.