When Scope Blows Up

In software engineering, there's an infamous but reoccurring situation, I think is relatable for every developer and project manager. You're never safe from it. It can assault you at any moment: During a peaceful standup, when reading issues on GitHub, or during lunch with co-workers. It's when the scope blows up having crept into your project's issues and code - mercilessly expanding and driving everyone nuts: "OMG, WE HAVE SCOPE CREEP!"

First, let's take a step back and define what is meant by scope creep. Intentionally, I'll focus on defining it from a manager's perspective because that's where I suspect it originates. So what is scope? I'd say that scope is the sum of all things needed to deliver a software product given a specific set of expectations and a date.

If we want to build an instant messenger app, its scope would likely encompass a feature that allows sending messages to others. Maybe it'd include sending smilies. Or photos. But what about voice calls? Well, that's where thinking in terms of scope becomes useful. If we deem that voice calls aren't part of our product offerings, we'd consider it "out of scope." That's when we'd say that "we've discovered scope creep" or that "scope is blowing up."

It's curious to see that the English Wikipedia article for Scope (project management) is tiny, considering how fundamental the concept seems to be in software engineering these days. Given this lack of rigid facts, however, I feel happy to just reason from my experience in the extension of this article. Continuing, I'll just shoot from the hip.

Here's a non-verified claim: Scope creep is subject to Murphy's law. So if scope can increase, it will increase. I'm not sure why that is, and indeed some behavioral psychologists have one day have an excellent explanation; but for now, you'll have to take it for what I've observed. I've said - when scope creeps, it's when everyone loses their minds.

But why? What is so bad about scope creep that people blame it for their company's failure, for leaving a job, or for burning out? It sure sounds like it encompasses incredible risk. And I think it does.

For a project manager and their team that's bound to deliver a roadmap, scope creep can make them look like failures and potentially lead to them missing out on future funding. Scope creep can mean the end of a project.

It's because for outsiders, given a lack of equal distribution of information about the project's challenges, scope creep can look like a team is failing or having lost focus. "Why are they not able to deliver their roadmap?", "This one feature, what does it have to do with the product's main value proposition?" "It looks like they're failing."

While, of course, from the inside, things can look dramatically different. Scope creep is seldom god's irrational punishment for the team's sins (lol dunno why I wrote that). Indeed, scope creep may just be the difference between expectations and reality. It may just be a specific lack of information. It may be a few thousand missing in the budget or the lack of a specific team mate.

I don't think, however, that scope creep is ever unjustified. Every scope creeper has a reason for creeping. It may be that their proposal is flawed and unnecessarily blown up. But ultimately, assuming that all contributors are good-natured towards the project, I've made the experience that a scope creeper (a person that blows up scope) is looking at the problem from a unique point of view and is seeing something others aren't.

I'd argue that as software engineers, we should embrace blowing up scope more. And we should learn to work with it. I know it sounds crazy, but your software management process can adapt to extracting immense value from knowledge processes by appropriately managing creeping scope.

I encourage you to think about scope creep like this: It's when you found a problem so vast and sinister that none of your team dares to face and slay it. It may be so huge; other teams may not dare to confront it either. Hell, it may be so colossal NOBODY HAS EVER dared.

But in turn, what does this mean economically? It means that you're leaving value behind. See, today's internet is oversaturated with life hacks, workarounds, and quick fixes. It's good because it lets you focus on the task at hand. It's bad because it makes us believe that focusing on the short-term is appropriate for solving problems. We're leaving value behind, an example:

Maybe you've used a tool like docker before, and given its complexity, at one point, you discovered this annoying bug. You could solve it yourself - but you fear it'd blow up your project's scope.

Upon searching the web, you find a GitHub issue created two years ago. It now has 1000 comments, and you scroll down to find the most appropriate workaround that fits your project's needs.

Now, considering that 1000 people each wasted one hour of their work time looking at this issue, I think it's easy to estimate the problem's weight. Hypothetically, would you solve it: It'd mean you could cash-in on saving a thousand well-paid developers one hour. Undoubtedly that's a massive amount of money.

The problem is: You cannot because it'd mean to blow up your job's scope ten or a thousandfold. And that's where I see an issue.

Assuming you'd be able to solve the issue on a technical and economic level, you'd progress in your career. But it's not possible - as there's neither unlimited budget on your project nor enough time or talent to subsidize you. So, inevitably, you'll hence go for the short-term workaround.

With all that in mind, I still think there's the chance to discover a deliberate practice to face scope creep more adventurously. Some scope creeps will inevitably make the project fail - even if handled carefully. Others - when solved correctly - may enrich your product and give you the right edge over the competition. What I believe should be avoided, though, is a compulsion and unjustified caution towards scope's increase.

You can think of solving a problem like traversing a tree or diving into a reef. You can go breadth-first or depth-first. Your mind is capable of back-tracking too. And even having traveled deeply, reality often offers the opportunity to resurface and take a breather before going down again.

So go out there young padawan - blow up some scopes!