Traditional vs. Agile
I often (though, these days it is less frequent*) come across folks who have practiced the traditional application methodologies, have heard of Agile development and are wary of Agile development. They all have their favorite pet peeve with the various flavors of Agile development – “two people coding together is a waste of resources”, “building before completing the entire design is surely a recipe for failure”, and so on…I have pondered this for a while and come to this understanding. The traditional methodologies are output driven (so many documents, checklists etc…) while agile development is outcome driven (does it work, does it satisfy the need, do the users want to use it?)
I was once on a “traditional” project for a large insurer. We completed the design (or, at least, we thought so), got the signoff and were waiting for the start of development. The client called us back and told us that on review against their methodology (which, they had licensed from a big consulting house which by then had stopped using that methodology in-house) they had found 20% gap in our design. I never figured how they came up on this 20%. My guess is that they reviewed the outputs against a list provided by the methodology and found some gaps.
Next time you are on an elevator and someone engages you on a traditional vs. agile discussion, try telling them that the difference is “output driven” vs. “outcome driven.”
