Why “scope creep” isn’t a dirty word
I’ve recently been interviewing for a new Delivery Manager and the phrase “scope creep” kept arising, for me this term feels somewhat outdated and redundant in the agile world we live in now.
I strive for the reverse, a team that embraces scope creep. Not to the degree where I want them to become “yes” people. I’m a big fan of the concept of saying a lot of small noes to ensure you deliver the big “yes” in most cases, a project on time and budget. Our role as an agency is to ensure that any change is bringing value to the business or the end-user, it’s serving a purpose and is essential for delivering the desired impact.
Scope creep has a negative connotation and I think it immediately suggests an element of conflict or someone losing out. I think in a world of prioritisation and agile development, scope creep can be a win-win.
However, any change needs to be managed and carefully controlled. I’ve seen many agile teams be too willing to accommodate change, in the end, to the detriment of the project.
Without a mechanism for managing the change and reporting in place, it can leave teams and agencies in dangerous territory, whereby you exhaust the budget but the solution is incomplete, this often ends up forcing the agency or the client to fork out at the final hour.
So what does positive “scope creep” look like
- it delivers business value
- it serves the users needs
- even better, the need has been validated
- it reduces complexity elsewhere in the product/project
- it improves the overall user experience
- it reduces manual effort in the business considerably i.e. there’s a cost-saving outside of the project
- the project can’t launch without it e.g. compliance, legal
- the change doesn’t impact the overall budget or timeline i.e. it’s small
If it’s a positive change, how do you ensure it doesn’t impact the overall budget and timeline
- more budget is secured once the feature is well defined enough to size
- it’s added as a ‘Should’ have ticket and prioritised for consideration at the end of the project
- the product owner decides this is a higher priority than something else on the backlog and it is substituted i.e. something else falls out as a result
- look at the ticket holistically within the area of the project or site e.g. if it falls into an epic or theme within the project, you reduce the complexity of the solution as a whole and hold a constraint for that area of the project e.g. you’ve dedicated a sprint worth of effort to onboarding a new user — this new feature takes 0.25 of a sprint, you’re constraint is therefore that the rest of the tickets related to onboarding fit within the remaining 0.75 in terms of effort
- slice the ticket into different tickets and ‘MoSCoW’ them, you may find that two tickets deliver 80% of the value and the two other tickets can be prioritised for a later phase
At Deeson, we use the DSDM agile framework to deliver our projects. These two principles are key in ensuring scope change of any description is well
Embrace change — the right solution will not evolve without it. Use iterative development to encourage creativity, experimentation and learning. Change is inevitable; DSDM allows for change and harnesses its benefits.
Demonstrate control — it is vital you always stay in control of the project, progress must be measured by looking at what has been delivered, rather than activities completed. The plan must be continually reviewed, visible and should also change based on the current reality of the progress of the project.
Product owners should always be in full control and fully aware of the implications of any decision they may, that in any way may impact the budget, timeline or not serve the needs of their business or users. I want to empower our clients to make well-informed decisions that they can stand behind. One of the principles I always try and stand behind is “No surprises”, good or bad.
