Embrace Changing Requirements or Work Hard to Reduce Uncertainty?
While the phrase “change is the only constant” is often attributed to the agile culture, the expression has been around for about twenty-five hundred years.
But what should agile development teams and practitioners do with all that guaranteed change? Should they embrace and encourage its presence, or should they first do everything in their power to reduce uncertainty, then deal with it as best they can—knowing that a complete removal of uncertainty is impossible, especially on an agile project?
The jury is still out.
A recent ITWeb article claims that agile projects don’t just deal with uncertainty, they thrive on it. The article references Martin Fowler, one of the Agile Manifesto’s authors, who explains that agile’s welcoming of changee, especially when it comes to requirements, doesn’t have to be as daunting as it may sound to those new to the practice. Fowler points out:
(L)etting go of predictability doesn't mean you have to revert to uncontrollable chaos. Instead, you need a process that can give you control over any unpredictability. That's what adaptivity is all about. …
A good predictive project will go according to plan; a good agile project will build something different and better than the original plan foresaw.
Isn’t there a limit to just how much uncertainty a development team or organization can handle, and if given the chance to reduce it, shouldn’t they do so? Kevin Thompson at cPrime makes a very strong case for reducing uncertainty from the areas where the amount can be decreased so that teams are better prepared to deal with uncertainty in the areas where they have less control. Thompson writes:
While we cannot eliminate uncertainty when estimating work, we can take some steps to reduce it. One way to reduce uncertainty is to reduce the size of the thing to be estimated. The fewer the elements are that must be considered when producing an estimate, the more reliable the estimate is likely to be. …
Reducing scope helps to reduce uncertainty, but only to a point. When uncertainty has been reduced as much as practical, the next step is to design the process to cope with uncertainty.
In what areas do you find uncertainty can, and should, be decreased? In which areas can uncertainty be a good thing?
