Webster defines incredible as: too extraordinary and improbable to be believed.
Most of the incredible successes of agile, are in fact, incredible. I’ll be blogging about how some of these successes were actually colossal failures.
But what is equally incredible are the claims, and so called logic, that props up the deceptions that are the foundation of agile.
To be agile is to be free from the constraints of logic, and if you don’t believe me:
How often do you see…
- Using opinions/statements as fact: “Agile means to do xyz” – It’s merely the opinion of the speaker, but it’s stated as a fact
- “Hyperproductive Scrum Teams” — while defining hyperproductivity in terms that are extremely suspect, such as using worst case as baseline, and using story points instead of real time units
- Calling Failures Successes– The C3 project that XP was initially used on was 6 years late and 50% complete. If it had been completed it would have been a dozen years late. That’s a success? Scrum was used at Easel, a bit player in the Smalltalk world before Scrum and just as much a bit player afterwards. Delighted customers? If there were any, they didn’t move the needle. Yahoo and Myspace were big Scrum users, even “hyperperforming” according to some reports. Hyperforming at lawndarting?
- “Do the simplest thing first” — Um, wouldn’t that be a prototype? But prototyping is forbidden in agile! Everything has to be “potentially shippable” (note: a mere statement of opinion by someone that has since been enshrined as fact) even given…
- “TDD” — if 90% of a system is never used, why write unit tests for it? If the situation is changing so often you don’t know what the customer wants, why write unit tests for it? Maybe after you decide what you want and the system stabilizes is a good time to write tests eh?
I could go on and on but please…. share your stories of the Incredible Logic of Agile!