Managing Scope Creep in Agile Projects
A short article by agile expert Kevin Aguanno on how to closely manage changes to project scope in agile projects so that you do not exceed contractual timelines/budgets.
by Kevin Aguanno, PMP, IPMA-B, MAPM
It has been drilled in to us that scope creep is a bad thing, that change should be minimized and avoided, and that changes should be charged to the client. Perhaps we need to unlearn these lessons as they are inflexible and may increase the risk of project failure. However, many people still worry that complete flexibility and continuous change to requirements can lead to scope creep, even with short incremental/agile development cycles. On a fixed price contract, for example, there is the risk of losing profit. How do the agile methods deal with scope creep and the risk that profit could be reduced using Agile? Is this a real risk? Does the Agile philosophy address this?
Agile methods are not for EVERY kind of project. For projects where scope will not change, more traditional methods are perhaps a better choice. However, where there are projects with high levels of change, Agile methods tend to be a better choice.
Scope creep is an interesting issue. The reality is that business requirements change (on certain projects) and the resulting scope of work changes in response. There is nothing we can do to stop the changing requirements, and not much we can do to stop the changing scope -- if the requirement is important enough and urgent enough, then the scope will change through a change request to the current scope of work, and if it is not urgent or important enough to interrupt the current scope of work, then the work will get done in a follow-on project. This is the same whether you are using Agile or traditional methods. So, scope will change (again, on certain projects) and probably SHOULD change, to increase the likelihood of delivering business value to the customer.
The question is how do we react to this change? On traditional projects, we either defer the change in scope until a future project (which can lead us to create "shelf-ware" -- software that none can use on release because it doesn't meet the current needs) or we engage in a rigorous change management process that sizes the impact of the change and gets authorization for the changes to the schedule/budget/risk/quality/etc. before we proceed. In agile projects, the two options remain the same. The difference is in how they are approached.
In traditional methods, project progress is slowed, and may even stop while the impact of changes is assessed and estimated. For changes that are eventually deferred to a future release, the investigation of these changes is a big waste of resources (time and money) that may impact the performance of the current project. The challenge is not knowing which ones can be deferred until the analysis is complete. In traditional sequential (waterfall) project approaches, these changes occur throughout the life of the project, and often occur during inconvenient project phases: a design change during the design phase is less troublesome than a design change during the final testing phase -- the latter requires going back to an earlier stage in the project and cycling through several phases all over again. Take the case of a defect found late in the testing phase that requires a design change to fix -- the project team now has to update the design, re-do some development work, and re-start testing (perhaps retesting everything, if you want full regression testing). In this case, such a defect found in the last weeks of testing may cause the project to go over budget and deliver after its target date if the defect needs to be corrected. (And finding such defects during testing is not at all uncommon...)
Agile methods handle this situation a bit differently. Changes are assessed throughout the project, and the scope is replanned at the start of each iteration. So, there is a natural break at the start of each iteration where upcoming scope items and upcoming change assessments are prioritized by the technical staff and the business sponsors. The team only does a detailed assessment of the impact of changes that are important enough to work on during the next iteration -- in this way, we don't delay the project by assessing changes that may be pushed out to later in the project or even into future follow-on projects. Additionally, with the continuous testing nature of agile projects, changes resulting from defects can be discovered and rectified almost immediately, reducing the risk of late-emerging defects impacting the project schedule. In the agile approach, changes are easily incorporated into the natural process of reprioritization and planning that takes place at the start of each iteration. It is a much more efficient use of scarce team resources.
Whether you are using a traditional or an agile method, once a change has been selected as important enough to work on right away (after whatever level of investigation/assessment and sizing work that you have done), you still need to get the proper authorizations to proceed. In either approach, the change authorization will have to describe the new scope and the required changes to the base agreement to incorporate the scope (time, budget, etc.). And this change authorization will need some type of formal approval. The processes and formats of these authorizations will differ depending upon the organizations involved and the types of contracts -- time and materials contracts often have less formal authorizations (though not always!) than fixed price contracts. So, at a high level, the change management discipline should still be rigorously applied in both traditional and agile methods. As described above, the impact of these change management processes are usually more severe in traditional methods than in agile methods, making agile methods an often better choice for high-change projects.
In either set of methods, strict adherence to proper change management procedures should adequately protect the profits of the vendor providing the project management services where scope changes occur. The risk of an out-of-control project scope is really the risk of having out-of-control project team leads. Proper training, management supervision, and disciplined adherence to standard change management processes should greatly reduce this risk.
So, scope creep is not really the problem. The problem is project team leaders who cannot work effectively with the sponsors to negotiate appropriate trade offs to the project constraints (time/budget/risk/quality/etc.) and who do not practice a sound change management discipline. Agile methods can help with this through their structural approach to change management.
This article is reproduced from the AgilePM Newsletter (C) 2008 Multi-Media Publications Inc. All rights reserved. For reprint information, please contact email@example.com.