Agile Change Management

My background is running Agile projects for external customers in the context of a contract, often fixed price.  That influences my focus on good project management and specifically change management. Change Management is the mechanism to combat scope/feature creep.

Within the Agile world scope change is expected and time is considered more important than functionality. So if something has to give to allow change then functionality/scope loses and time wins. To do this the customer must make Requirements Trade-offs. The Customer directs development in Timebox and minor changes are just accepted. Big changes are handled different depending on whether it is a change to the Release Plan or Timebox Plan.

This article covers defining change management, traditional change management, Agile versus traditional change management, the role of the Agile Project Manager in change management, changes to the Release Plan, and changes to the Timebox Plan.

Cohn (2006) and Beck and Fowler (2001) are probably the best books that cover change management in Agile.  Of course the XP guys “embrace change” and have a mechanism for dealing with it.  Mike Cohn has embellished Scrum with many sensible additions making it more robust from a project management perspective.

Others believe controlling change is not important in Agile.  The basic version of Scrum (Schwaber & Beddle, 2002) and Lean Software Development (Poppendieck & Poppendieck, 2003) are more about product development than project management so are largely concerned about what is delivered rather than tracking the cost and time to do it.  Lean would, for example, consider that type of tracking activity wasteful.  None the less I’d recommend having a look at Scrum and Lean because they offer a lot in other areas and your situation may warrant less of a focus on managing change.

Defining Change Management

According to Wikipedia: Change management (Engineering)

The change management process in systems engineering is the process of requesting, determining attainability, planning, implementing and evaluation of changes to a system. It has two main goals : supporting the processing of changes … and enabling traceability of changes.

Although this definition is for systems engineering change management in software development projects has followed the same model.

Change control comprises the procedures used to ensure that changes are introduced in a controlled and coordinated manner.

Traditional Change Management

The Prince2 manual is pretty explicit about change (OGC, 2005, p. 81):

Changes to specification or scope can potentially ruin any project unless they are carefully controlled. Change is, however, highly likely. The control of change means the assessment of the impact of potential changes, their importance, their cost and a judgemental decision by management on whether to include them or not. Any approved changes must be reflected in any necessary corresponding change to schedule and budget. “Management” in the Prince2 context means either the Project Board or a subordinate group called the Change Authority. For simplicity I’ll refer to the Change Authority in the description of the process except where Project Board is explicitly intended.

cost-time-scope-quality triangleProject sponsors allocate a scope, cost and time to a project with an implicit “high quality” attribute underlying this.  In traditional project management these are baselined, i.e. locked down, at the start of a project.  The project manager’s job is to ensure the project delivers the desired scope, in the time allowed, within the budget allocated, and to the quality aspired to.  If any of these attributes shifts from the baseline then change management cuts in. Typically in a traditional project that means that new features (scope) are requested and the project takes longer and costs more or quality suffers.

The change control procedure recommended by Prince2 is:

  1. Raise a Request for Change (or Off-specification , i.e. defect)
  2. Log, assign a priority, and acknowledge the Request for Change
  3. Conduct an Impact Analysis and re-evaluate the Request for Change
  4. For products that have not been signed off by the Project Board the Project Manager has option to approve the Request for change if it is possible do the work within stage and project tolerance margins (i.e. within allowed cost and time). If they Project Manager approves they raise an Exception Authority. The Project Manager cannot authorise any changes to a product that has already been signed off by the Project Board.
  5. If the Project Manager doesn’t approve, then escalate the Requests for Change to the Change Authority for approval. Approval leads to an Exception Plan and is likely to result in additional cost or time.
  6. Update the log

It is normal for the Change Authority to meet at a regular intervals, such as weekly, fortnightly, monthly. Project Boards usually meet monthly.

Agile versus Traditional Change Management

In my opinion the underlying Change Management principles are the same whether the project is traditional or Agile.  Even in Agile projects changes have to be managed, but the way this is done differs and the underlying assumptions differ. One of the Principles Behind the Agile Manifesto is:

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

cost-time-scope-quality triangleAs mentioned above project sponsors allocate a scope, cost and time to a project with an implicit “high quality” attribute underlying this.  Most Agile methods assumed that cost, time and quality are fixed, and only scope can change.  Typically in a traditional project new features (scope) are requested and that means the project takes longer and costs more.  In an Agile project the team commits to delivering on a fixed date for a certain cost, and to do that there must be flexibility in scope.  The reason this can work is that the high priority requirements, those offering most business value, are delivered first.  So by the end of the fixed time allocated most of the business value has already been gained and the project can be a success without delivering everything.

Essentially, in an Agile project, the authority to approve many changes is delegated to the roles in the Agile Team. The specific differences are:

  • The Product Owner and Project Manager have more authority to approve change.
  • Minor changes are just done.
  • Requirements trade-off is used to allow larger changes and still keep the project within tolerance.

But if a change threatens the project, i.e. if it is going to cost more or take longer, then the decision must still be escalated to the appropriate change authority. In other words, you don’t need approval outside the Agile Team for most changes. Only those requiring more time or more money are escalated.

Role of the Agile Project Manager in Change Management

The Project Manager is the gate keeper of the various plans and the associated Agile Project Scope. They protect the team from external pressures regarding new work and the project from feature creep and gold plating. The Project Manager is responsible for communicating changes to Agile Project Scope. They must keep the Agile Team, the Product Owner, and the Change Authority informed of all changes. They must also keep the various plans up to date as changes are made.

Changes to the Release Plan

The Release Plan and the User Stories on it defines the Agile Project Scope. The Product Owner can add/delete/change User Stories as long as the total estimate for all in-scope User Stories is unchanged. Requirements Trade-off is the way to do this.

Requirements Trade-off

Requirements Trade-off is the process of swapping User Stories in and out of the Release Plan. If a new User Story comes up, which the Product Owner thinks is higher priority than other User Stories, they can add it to the Release Plan, but something else has to be dropped. The new User Story can no bigger than the old User Story it replaces because the total estimate for all User Stories doesn’t increase. This sort of change doesn’t threaten the project as the total cost and time should be unchanged. Obviously new User Stories need to estimated (see Agile Project Estimating). It is a good idea to inform the Change Authority what is happening, but you don’t have to wait for their approval.

Velocity and Change Management

Velocity is an empirical measure of the team’s capacity to develop software. Being empirical it may change during the project, particularly if it was guessed at the beginning. Big changes in Velocity will invalidate the Release Plan. An increase in Velocity isn’t so bad as it means the Agile Team will delivery early. A decrease in Velocity shows that the Agile Team will not be able to deliver everything in the current Agile Project Scope. To balance the Release Plan the Product Owner will have to drop User Stories until the Agile Project Scope is small enough and corresponds to the new Velocity. The Project Manager should inform the Change Authority that this has happened, but once again you don’t have to wait for approval. Agile Project Scope has reduced but time and cost are still ok.

Escalating to the Change Authority

Agile projects still need a Change Authority. This is the group that approves extra time and/or cost. The Project Manager escalate two events to the Change Authority for approval:

  • any additions/updates/deletions to User Stories that cause the Agile Project Scope to increase
  • any drops in Velocity where Agile Project Scope isn’t reduced to match If the Change Authority approves the change they must also approve the extra time and/or cost that goes with it.

Change Within a Timebox

The Timebox Plan lists the Tasks the team has committed to doing during the Timebox. There are several possible changes to the Timebox Plan:

  1. A Task is harder than expected putting the Agile Team behind schedule
  2. A Task is easier than expected putting the Agile Team ahead of schedule
  3. A particular team member can’t pick up any of the remaining Tasks from the Timebox Plan
  4. The Product Owner arbitrarily decides to add a User Story to the Timebox

As a team member works on a Task they may realise the User Story is more complicated than expected. This may require increasing the estimate for the Task or adding a new Task to the Timebox Plan. If this means the Agile Team can no longer complete all Tasks by the end of the Timebox the Agile Team must drop Tasks or the Product Owner must drop whole User Stories.

More positively the Agile Team might get through the Tasks faster than expected. The Product Owner can add User Stories to the Timebox to fill the gap. Similarly, if a particular team member can’t pick up any of the remaining Tasks in the Timebox (because they lack the specialist knowledge or someone else is working on them), the Product Owner can add new Stories into the Timebox. As per Agile Project Planning the Agile Team then create Tasks for the new User Stories.

There are two options if the Product Owner tries to add a new User Story during a Timebox:

  1. Just say “No”! This is the Scrum approach.
  2. Use Requirements Trade-off to make room.

Change during a Timebox will invariably cost the customer money because some work will have discarded.  The Product Owner has to be aware of this implication and accept the responsibility.

References

Beck, K, & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley.

Cohn, M. (2006). Agile Estimating and Planning. Prentice Hall.

OGC. (2005). Managing Successful Projects with Prince2. TSO.

Poppendieck, M., and Poppendieck T. (2003). Lean Software Development: An Agile Toolkit for Software Development Managers.

Schwaber, K., & Beddle, M. (2002). Agile Software Development with Scrum. NJ: Prentice Hall.

Wikipedia: Change management (Engineering)