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:
- Also from Craig Larman, Iterative and Evolutionary
- Overcoming cultural challenges in adopting iterative development , by Clay Nelson, The Rational Edge, October 2004
- Philippe Kruchten's article From Waterfall to Iterative Development: A tough transition for project managers (Rational Edge, December 2000) and Going Over the Waterfall with the RUP (Rational Edge, April 2004)
- Per Kroll's Transitioning from Waterfall to Iterative Development (Rational Edge, April 2004)
- Kurt Bittner's What is Iterative Development? Part III: The Management Perspective (also see Part II: the Customer Perspective , and Part I: The Developer Perspective ), from the Rational Edge, Mar-May 2005
- Effective Governance practices for iterative software development, Mark Lines (Rational Edge, Feb 2005)
- Iterative Software project planning and tracking , Johanna Rothman
- 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 et.al., from DF-16 (Datateknisk Forum), Denmark 2001
- A Report of Development Lifecycle Methodologies Compared
- Controlling Iterative Software Development projects - The Challenge of Stakeholder & Technical Integration , by