Scope creep or just change?

It starts with “Can you just …?” “What about …” or “Don’t kill me but …?” What comes next is a new idea, feature, or request that hasn’t come up before. This conversation happens all the time and it causes a lot of grumbling about “scope creep”.

But if you consider learning and discovery to be a natural part of the software development process, there is truly no such thing as scope creep. It’s just change managed badly.

We don’t know what we need when we get started. New things always come up. Customer needs change. Market forces change. People outside of the team come up with new ideas. People on the team come up with new ideas. This constant change is the only thing we can count on. So let’s stop pretending we can stop it and get better at managing it.

Embrace learning

One of the problems with the term scope creep is that it implies that we haven’t done our job well enough.  It implies that someone, somewhere, messed up and if we were just better managers then this wouldn’t have happened.  We would have foreseen all of the possible requests or we would have the backbone or skills to say “no” every time someone has a new idea.  It implies that the scope creep is a scary monster that needs to be kept at bay by an ever-vigilant product manager jealously guarding the barn door.

This discourages change and learning.  One of the lessons from the agile software development movement is that there is no reliable way adequately to specify in advance what we ought to build.  Learning needs to take place in order for us to converge on an ideal solution.

The development team needs to learn about what is possible within the constraints of the tools and technology available to them. Product managers need to validate their assumptions about what particular feature or application of technology is most likely to meet a need, while product consumers often truly don’t know what they want until they see it.

We may think that a given solution will be ideal when we consider it on paper or on a whiteboard, but when we put an app in the hands of a user, we will always get new insights and deeper understanding about what the “right” thing to build is. Learning is something to be embraced and not feared.

Managing change is a skill

A development team has a fixed capacity, and no amount of wishing, prodding or coercing will create a more significant output.  Instead, successful change management is the art of optimizing the work that is done within that capacity.

It starts with a process for collecting all of the new ideas, requests, and learning from across your organization. Patterns will emerge, showing what new things are most important.  Managing change does not mean acting on all of these ideas;  rather it means finding the balance between being responsive and disruptive.

If we have a robust process for managing to our capacity, we can consider as many new ideas as we want, knowing that the process will require us to commit to only as much as we can reasonably do.  Teams stop fearing scope creep when they realize that new ideas don’t automatically mean more late nights.

Some new ideas that arise are good enough that they should displace old ideas.  Some are not as good as what we already have, and should be discarded.  And sometimes combining an old idea with a new one creates something magical.

Finally, we need a reasonable rhythm for considering new ideas and changing direction.  If a team is consuming a lot of time every day considering new things, they probably aren’t making progress on the product. Some agile methods specify a short, time-boxed period within which no changes to what the team is working on are allowed. But then everything is up for consideration at the boundaries of the timebox.

Scope creep is an imaginary enemy

We absolutely don’t have the time or resources to act on all of the good ideas that get put on the table during the course of the project.  But acting on a few of those ideas can be essential.

So the next time a new request comes in, stop and consider it. That scope creep you’ve been resisting might just be the thing that makes your product succeed.