In spite of all the PDA (Public Displays of Agility) among the agile hippies (“make love, not specs”), some teams/divisions/companies still cling to the old waterfall-like processes. All well and good… even the most fanatical agile hippies admit that agile is not for everyone. But often enough, a team finds itself needing to be more dynamic and responsive to change, while afraid of the big bad buzzword “Agile”. These teams are what I call “agile in denial” (AID).
Signs of an “agile in denial” team:
- They write big or multiple functional specs, but keep changing them until the feature ships
- They have upfront scopes for each release, but end up dropping or modifying large chunks of the said scope as the iteration progresses.
- They designate “feature freeze” dates, each of which is preceded by a mad rush to implement as many features as possible, however shoddily, and put off quality control and/or bug fixing until after the feature freeze.
The detriments of the use of megaspecs to try to cement fluid requirements have been explored well enough – mostly teams end up losing valuable time and resources making (and committing to) plans they will end up not following. But when a team tries to maintain feature freeze dates while succumbing to variability of requirements and scoping, all hell breaks loose.
Let’s do a word problem together: Pretend you’ve entered a very expensive gourmet all-you-can-eat restaurant. Every delicacy you have ever dreamed of is spread out on the buffet line before you. Just a couple of snags: First, an hour from now the restaurant will close and you’ll have to end your meal. And second, ten minutes from now the buffet line will close, so you have only ten minutes to fill your table with all the food you plan to eat during the meal. Question: what percentage of the food brought to the table during the first ten minutes will be consumed by the end of the meal?
A delicious, if unnecessary parable. Feature freeze dates are great if the requirements are firm and the scoping is realistic. But when the scope is prone to change as the work progresses, a hungry PM will almost inevitably succumb to temptation to fill his table with many delicious features from the buffet line prior to the feature freeze, without thought as to whether the team will have time to eat and digest (debug and QA) the selection thoroughly before the release date.
And so we reach the fourth and most tragic sign of an agile team in denial:
- Their releases advertise many new features, but are full of bugs in aspects new and old. Releases often cannot be used to satisfaction until a patch or two has been provided.