Environmental change is a hot topic nowadays. And though the possible causes for global warming are still being disputed – I’m quite sure that it’s not my fault – everyone understands that people must learn to adapt to a changing environment. Trying to fight change is like me trying to prevent traffic jams. There’s no point in being silly other than amusing those who know better. The ubiquity of change is nothing new, of course. The global climate has never stopped changing. The oceans and the sun have their moods too. Ice ages come and go. I deal with these changes by buying nice clothes, or taking them off. My car has air-conditioning, and someday I might swap it for a yacht.
The quote “change is the only constant” is attributed to Greek philosopher Heraclitus, and only those who “embrace change” – the subtitle of Kent Beck’s famous XP book – are able to survive. In biology, the performance system that enables continuous adaptation is natural selection. One of the best known examples of natural selection is the story of the peppered moth (Biston betularia). During the industrial revolution, the black form of the peppered moth became much more common than the more typical pale form. The moths, which rest with open wings on tree bark, adapted their wing color when the trees in polluted areas of Britain became dark and sooty. (Air pollution in those days was a hundred times worse than it is now.) Predator birds had an easy time picking out the pale moths, while the dark ones became harder to find. The moths simply returned to their original wing color when the air cleared in later decennia.
These days it is an established fact that software must be able to adapt to environmental changes, and not just by adapting colors or coolers. Authors Robert L. Glass and Frederick P. Brooks both described that successful software requires more maintenance than unsuccessful software. The reason is that users like to try their favorite software in new unanticipated situations, and because successful software tends to outlive the hardware, business processes and users that were expected and considered during its initial creation. Both are variants of a changing environment, and they lead to software change requests. The Manifesto for Agile Software Development names “Responding to change” as one of its core principles. This is in stark contrast with the more traditional view that assumes that projects can be handled in stable environments. The PRINCE2 methodology – an acronym for Projects in Controlled Environments – is an example of this view. If environments could be controlled the peppered moth might have found it easier to change the color of the tree bark, instead of its own wing color. (And I would have bought myself an open car instead of a glass roof.) But environments most often cannot be controlled, and software projects simply have to adapt.
It is worth pointing out that a changing environment does not necessarily translate to a changing project scope (new features or revised quality). The two other sides of the Iron Triangle are Time and Resources, and they are also subject to change – like a changed timeline for product releases, or changes in resources (people and tools). It is interesting to note that agile methods usually describe only processes for dealing with scope change. I know of no methods explicitly defining processes for handling variable time or variable resources. In fact, the most common argument is that, of the three variables time, scope and resources, only time and resources can be “fixed”, or specified as being “constant”, while scope remains as the only variable. (This is what timeboxing is all about.) But in a real environment everything is a variable. Scope is simply the easiest of the three to use for adaptive strategies in situations where any of the three variables has changed. This is why agile methods focus on managing variable scope, but it doesn’t mean that resources and time need no management. They do. Resource management and time management are essential in any organization and any project. They are just not covered by standard methodologies, and you will have to discover your rules and best practices elsewhere. Google and Amazon can be of great help here.
When I’m driving and heading for some important meeting, I often try to take care of all three variables scope, time and resources. Traffic jams and road works are a nuisance in my country, which means that I have to take into account the possibility of increased scope (alternative and often longer routes that get me where I need to be). My appointments (expected time and duration) sometimes change suddenly, always beyond my control, which is why I keep my mobile phone with me wherever I go. And my beloved car might fail me someday – only theoretically, of course – as my primary resource, which is why I carry a 24-hour road assistance card with me. And I always have a bath towel in the trunk. You just never know when global warming is going to hit us.