Agile Doesn’t Mean Accept All Change!

With few exceptions, gone are the days when a team would plan a business project to a low level of detail, secure approval from their customer on scope, schedule and cost baselines, and then not have to be concerned about anything changing over the project’s lifetime.

The greater the level of requirements uncertainty or the more dynamic the enterprise environmental factors and competitive pressures are, the greater the likelihood of change.

On a traditional project, two common alternatives are practiced.

If short-term profit motives, fixed timelines or limited budget are the priority, then applying strict project change control practices ensures that change is managed, but likely at the cost of customer good-will. Taken to the extreme, administrative and analytical efforts spent on analyzing multiple change requests might actually prevent the team from delivering scope in a timely or cost-effective fashion.

If customer satisfaction trumps everything else, then scope creep might be encouraged and the delivery organization absorbs the costs of the additional work. However, the clock keeps ticking and even if the customer is not out-of-pocket as a result of these changes, their time-to-market objectives may not be met.

Agile projects are supposed to address this challenge. Rather than considering change as an evil interloper to be shunned at all costs, it is welcomed as an expected guest that will ensure the project team delivers the right scope to achieve expected business outcomes.
But does this mean that there should be NO change control on agile projects? Unfortunately, this is one of the pervasive myths of agile. Agile doesn’t imply throwing out tried and tested practices but rather encourages the use of the right tool for the right job in the right manner.

Without some level of change control, two scope management issues could emerge.

1. Fundamental architectural elements are expected to be designed, implemented, refactored and stabilized in early iterations. However, if new work items get added by the project owner which imply significant changes to the implemented architecture, these changes might negatively impact deliverables which have already been transitioned to an operational state. This will result in a lot of re-work. The implications of this re-work could cause the team to be unable to meet a customer’s minimally acceptable product needs within their approved cost and schedule constraints. Additionally, team members might experience a drop in morale and productivity as they’d witness that a significant portion of their previous work effort had been wasted.
2. The project owner takes the team on a work item walkabout. Instead of scope getting refined and distilled through progressive iterations, the project owner continues to introduce new critical requirements in each iteration which appear to have very little to do with those identified before. The team completes work items at a good velocity, but the backlog never seems to shrink and once again, the likelihood of the team delivering a minimally acceptable product on time and on budget is reduced.

Do either of these scenarios mean that the project manager should turn a blind eye to what is going on or should whip out their handy PCR template and enact strict change control?
They could, but that would be a regression to traditional methods of dealing with change.
A different approach might be to have a discussion with the project owner at the end of the current iteration as part of the planning for the next iteration. The project manager should provide the project owner with a facts-based revised iteration plan and request a decision on how to proceed.

Faced with this information, a project owner usually has the following three choices.

1. If the underlying rationale supporting the business case is no longer sufficiently compelling to justify further investment, and the significant shifts in scope actually are signs that a new project should be justified and initiated, it might make sense to stop the project.
2. If the project owner is willing to fund additional iterations beyond the current plan then they can provide team members with a better understanding as to why the significant shifts in scope are occurring and the team can continue their work with renewed vigor.
3. If additional iterations cannot be funded or if a minimally acceptable product has to be delivered by the end of the current iteration plan, then the project owner will need to reprioritize the backlog with support from the team to fit within the current iteration plan.

On well-managed agile projects, change does not get suppressed, nor does it get free rein. It is appropriately managed to deliver business value in a time and cost effective manner.