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

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.