The Unchangeable Rules of Software Change

[article]

makes it slip out of control

The more you try to deny and defy rule #2 by attempting to precisely predict, or rigidly control change, the more erratic and onerous the result will be.

Rule #4: Embrace change to control change

The more flexible and adaptive you are at accommodating change, the more control you will have over your outcomes.

These rules are very hard to accept! Often, they are accepted only one at a time, after much frustration and over a period of hard learning and reflection. The stages one passes through while learning these rules bears more than a passing resemblance to "the five stages of grief."

Traditional Change-Control
When faced with a requested or impending change that impacts the scope of the project, generally accepted best-practice is to utilize a Change-Control Board (CCB) consisting of your project's key stakeholders:

    • Assess the impacts of the change make those known to your stakeholders
    • Present the viable options the risks associated with each one (possibly accompanied by a recommendation)
    • Let them decide which option to "exercise" based on informed consent, making sure they are fully cognizant of the benefits, consequences, and risks of the chosen option.

Still, the idea of giving up control to another group every time a change arises isn't always palatable. And of course there is also the fear that every a scope change that becomes visible will make them look bad, as if they don't really know what they are doing.

Recently I was talking to a group that was struggling with rule #2. They thought if they could only do even more detailed specification up-front (they already do a reasonable amount of up-front detail), that it would somehow eliminate problems with estimation accuracy, which in turn would alleviate problems with "conformance to plan" and prevent the details from being discovered later (because they would instead get them all "right" up-front).

Despite having plenty of historical evidence/data in this particular product to support the "inescapable truth" laid out by these rules, there still seemed to be that desire to cling to the illusion of control that we can somehow prevent such changes if only we spend more time & effort getting a more complete, perfect & detailed specification up-front near the very beginning.

Software Evolution & Feedback
As it so happens, I don't always come across as authoritatively sage as I might hope. So I looked for some materials from other folks more sagacious and experienced than myself. The first that came to mind was Lehman and Belady's Laws of Software Evolution (ca.1971) and the subsequent work on the FEAST Projects . Those are primarily about software maintenance however, and refer to the inevitability of needing to maintain and evolve an already released piece of software. They don't speak quite as strongly to the inevitability of changes via feedback, discovery and learning during the course of any non-trivial software development effort.

So I searched a bit more and came across a handful of particularly interesting (to me) references that are quite recent:

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!