The Unchangeable Rules of Software Change


is to deal with and adjust to reality.

As Winston Churchill once said "Plans are of little importance, but planning is essential" -- Dwight Eisenhower said it much the same way: Plans are nothing; planning is everything!" But conforming to reality must takes precedence over conformance to "the plan" (trust the terrain, not the map!). More recently, James Highsmith wrote: "Agile projects are not controlled by conformance to plan but by conformance to business value.... If we accept the notion of constant change and turbulence, then plans are still useful as guides, but not as control mechanisms -- because they tend to punish correct actions."

It may seem counter-intuitive for some, but in the current era of business software development, "Change" is not the enemy -- stagnation is! Mary Poppendieck notes that: "Requirements changes late in the lifecycle are competitive advantage, IF you can act on them!"

How does all this relate to traditional CCBs and how does it change "change control" for agile and iterative development? It means that:

    • Plans and requirements are still necessary to identify, but should be elaborated iteratively in progressively more detail, usually a feature at a time.
    • Regular (e.g., at least weekly) milestones are still important to set and track -- don't forget to do that just because you're working in short, fast increments
    • Incremental integration needs to be even more frequent (and automated) when iterations are short
    • Manage stakeholder expectations with close communication and simple boundaries (short, frequent iterations)
    • If iterations are very short, there is little opportunity to work on anything but the agreed upon features for the current iteration. In this case, CCBs are really just iteration planning meetings with your stakeholders at the beginning of each iteration.
    • CCB's and related decision-makers must be more dynamic, comprised of stakeholders that are readily available and accessible to give rapid response to issues and questions soon after they arise.
    • At the start of each iteration, expectations and priorities are (re)set and (re)calibrated

Iterative Development Resources:
Of course, saying "do iterative development" is one thing. Figuring out how to actually do it for a group in an organization that isn't accustomed to it is another thing entirely. So here is a list of resources on the subject of adopting, planning/managing, and doing iterative software development -- particularly for those coming from a background of phased-sequential (waterfall or "V") model of planning:

    • Effective Governance practices for iterative software development, Mark Lines (Rational Edge, Feb 2005)
    • Heuristics for Iterative Software Development, by Drako Sotirovski, IEEE Software May/June 2001, Involving Customers Early and Often in a Software Development Project, Laura Rose, Rational Edge, January 2006
    • Iterative Software Development - a Practical View, by Morten Korsaa, from DF-16 (Datateknisk Forum), Denmark 2001 (and some very nice accompanying

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 or visit and follow his blog at

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 book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

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, is the place to go for what is happening in software development and delivery.  Join the conversation now!