I've been a football fan since I was about five years old. I have studied this game for almost thirty years, so forgive me if I bore you all with a trite football analogy. This is the old saw known as "fast vs. quick". Players like Barry Sanders or Walter Payton were "quick", but not necessarily fast. In general, "fast" guys are wide receivers and corner-backs (the guys that cover the receivers). Receives generally have further to run than running backs, so they need what is called "breakaway speed" which is enough raw power to get away from the defender covering them.
Running backs however, need a combination of strength and the ability to move their bodies very quickly in a very small space. The difference between a gain of one or two yards and a breaking-off a twenty-yard run is usually a matter of inches. The runner has to be in just the right place at just the right moment and get just the right kind of blocking from his teammates. Quickness is the ability to shift weight, turn the body and plant a foot just a fraction of second faster than the next guy. It's what separates the good from the truly great.
Hall of Fame running backs rarely survive on pure speed alone. Heck, most backs that were "burners" in college are usually forced to play another position at the professional level. Those that try to rely on pure brawn to break tackles generally don't last long (see, Eddie George, Priest Holmes or any back that has played in Denver in the last decade). The really great ones have that ethereal quality known as "quickness".
So, I was thinking lately about "agile" in the software world and what it really means. The term agile, isn't clear enough—it could be fast or it could be quick. But which really matters? Which is the quality you really want to have?
My answer? You want the agility associated with quickness, not raw speed. Being "quick" in software might look like: * New requirements are handled in-stride and rarely, if ever, with The Big Re-Write * The time to produce a meaningful feature is measured in hours or days, not weeks * The time to produce a meaningful release is measured in days or weeks, not months * The system almost never looks like the original design
OK, so what would "fast" look like? Well… * Releases are buggy * Few if any tests * Code diarrhea * Quality is inconsistent * There are lots of dependencies * New requirements are an exercise in hammering reality into fixed model
Actually, none of those sound particularly "fast" to me.
When folks complain about the ineffectiveness of "Agile", I sometimes wonder if they aren't simply confusing fast with quick. There isn't any methodology or toolset I know of that will make you faster. Your raw speed is determined more or less by the skill of your team. Each member transfers a concept into code at a relatively consistent rate, so you simply aren't going to go any faster unless you change your team. However I think you can acquire new skills to improve your quickness.