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

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.