The Unchangeable Rules of Software Change

    • on Jan 6, 2006:

The fundamentally difficult hurdle managers need to come across is that when you do not know enough to produce an accurate estimate, it will not help to do a more fine-granular plan. Rather, you need to do a list of what are the unknowns and risks preventing you from doing a more detailed estimate, and then rapidly do the analysis, design, implementation, testing, or other risk mitigation turning unknowns into knowns. This sounds as something that should not be very difficult to understand, but it really is a big mountain to climb for many people...

Iterative Development to the Rescue?
One of the things the particular team finally figured out it needed was to try and use iterative development as a means of managing change and being more responsive to customer feedback while still controlling scope:

    • One of the ways in which iterative development is most effective at controlling change is that it shortens the time-window of opportunity during which changes can occur!
    • The other is that it shortens the cycle-time of the feedback-loop for obtaining validation of our end-result. The sooner we can see tangible executable and obtain stakeholder feedback, the more we reduce the risk of unmet expectations and the associated cost of rework!

Sounds simple - right? The answer our prayers is clearly iterative development! Of course! (It's all so obvious now!) All we need to do is iterate! That's what so many of these groups often do next. Well, as you might have guessed, their first attempt at iterative development doesn't quite work as they expected. They often run into three more pitfalls: 

Pitfall #4: Insufficient Requirements Analysis

Thinking iterative development the "silver bullet" to their requirements problems, they abandon all or most of the requirements analysis they had been doing, and don't understand the requirements as well as they should before starting to code.

Pitfall #5: No iteration planning

They jump into iterative development in an overly ad-hoc fashion, without a suitable iteration plan for each iteration. They naively assumed "going iterative" would eliminate the need to define specific goals and milestones for each iteration at the inch/pebble level.

Pitfall #6: Too much iteration planning 

Once again, on the heels of their previous failure, they go too far to the other extreme and try to apply all the formality and rigor of planning a large project to the planning of each iteration. They burden themselves with an amount of project management and tracking effort that was intended to take place over many months and try to squeeze all of it into a period of a few weeks.

Walking the Tightrope and Avoiding the Pitfalls
I've seen teams that ran into all of these pitfalls as well. The remedy for these three latest pitfalls is not necessarily to fall back into trying to overanalyze and overspecify detailed plans and requirements on a per-iteration basis. Some initial amount of planning and requirements is necessary to know where you are trying to go and what to estimate. The remedy is to stop bouncing back and forth between extremes, and instead of doing all or nothing "up front," do a reasonable initial amount and then incrementally and iteratively flesh out each individual piece, instead of trying to do scores or hundreds of partially completed pieces all at the same time.

Good change and configuration management is supposed to be about facilitating change, not about preventing it. That's what the Agile Manifesto really means when it talks about "Responding to Change over Following a Plan." The point isn't to discard or dismiss plans or planning, it

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!