Traditional Project Management approaches focused very much on trying to control change. A lot of emphasis gets placed on managing change requests, implementing change approval processes and assessing the costs associated with modifications.
With Agile we’re continually being reminded to embrace change. The mindset has changed to one that recognises that an evolving solution will better meet the customer’s needs, and will get delivered more quickly and efficiently.
However, we are sometimes at risk of taking this acceptance of change to extremes on projects, and this creates a new set of problems that were precisely the ones that more traditional approaches were trying to guard against. We need to recognise that not all changes are created equal. DSDM’s Agile Project Framework highlights that there can be two fundamental types of change, change in the breadth or the depth of the requirements.
Changes in depth are the kind of changes that Agile embraces. These are the changes that arise from the evolving design and from performing just Enough Design Up Front. The details emerge as the solution development progresses. The solution evolves and improves in ways that could not have occurred if following a more traditional Big Design Up Front approach. Planned features may be dropped for numerous reasons, allowing the adding of newer higher value features in their place. The detailed implementation of a solution may change to account for new technologies or organisational changes. All of which is why Agile’s embracing of change is such a good thing.
Changes in breadth, however, are more complicated and significant. Changes in breadth include the addition of whole sets of new functionality or features. Such changes represent an expansion of the product in development. They can represent significant changes in skill sets required by the project team building the solution and/or increases in the duration and cost of the project. Accepting these changes on Agile projects is still possible. However, they require more assessment before doing so. Failure to perform such evaluations puts the project at risk of ongoing scope creep and can delay the project’s closure. The benefits, and costs, of such changes, need to reviewed before rushing them into the upcoming Sprint.
DSDM’s Agile Project Framework addresses this by allowing changes in depth as part of the ongoing Evolutionary Development of the solution. However, changes in breadth require a revisiting of the Foundations and potentially Feasibility phases to perform the related benefits and feasibility assessments on the requested changes.
Recognising that there are two types of change that solution development is subject to can help to keep projects on track. Knowing how to handle each type of change helps ensure that focus is maintained on the solution while simultaneously preventing the project from undergoing never ending scope creep.