I’m late to the Agile party, I know… but I cannot help but keep seeing many failures and shortcomings of the past being accepted, welcomed, and then addressed in the Agile space.
How many times have you busted your head open trying to estimate a requirement of something completely unknown? How about spending that extra time (late night/weekend) building in some “cushion” on a function that you could imagine being requested in the next month? How many times have you seen the same good estimate track perfectly until it meets the reality of dependencies inside the product or is the next episode of “The Customer Tweak of the Week”?!
Well, wake up, you’re in waterfall land and hardly anyone actually works by that discipline. We may say we do waterfall, but have you ever told your customer NO for each and every request once the project was underway? Probably not…
If you were merciful like the rest of us, you were being adaptive.
James Short wrote up an article on some of his mentoring of XP, but the part I really enjoyed was the realistic approach Agile takes: put off a decision until the “last responsible moment” so that you have as much of the information and as little assumption going into your decision. The decision in this case means to write up a specification.
In the same vein, you need to also remember to only spec for the present, instead of trying to build up a super infrastructure for all possible scenarios of the feature you’re implementing at the moment. We need to trust, no rely, on a metholody (TDD + Refactoring) that will flush out design inefficiencies and let us go back and put those in when they are finally needed. Again, do not built today something that isn’t needed today.