November 15, 2021

Lesson 12: Scope Creep

Lesson 12: Scope Creep

Creep is such an insulting word. I dare you to try and use the word creep in any of its parts of speech (noun, verb, adjective) with a positive connotation.

“Do you take this creep to be your lawfully wedded husband?”

Nope.

“Let’s creep over to the neighbor's house tonight.”

Nope.

“Creepy Birthday to You!”

Nope.

You can’t do it.

So it shouldn’t surprise you that there is a a term in software development that uses this devilish word to denote the most hideous thing that can happen to any development initiative…

…I’m talking about scope creep.

It’s an act so sinful that that even Moses struggled with what should be the 10th commandment.

“I have a tough decision to make,” he thought to himself upon Mt. Sanai. “Thou Shalt Not Covet or Thou Shalt Not Scope Creep”…

…Let’s be real, people have been stoned to death for much less grievous offenses than scope creep.

Now it would be one thing if scope creep was a term generally used for all the people and all the situations it could be applied to. But trust me, such a damning word like scope creep is reserved for and mentioned only in context of the instigators of insidiousness, those wretched Product Managers…

…in the software development world, only an unworthy and unforgiven Product Manager could do something so evil and horrific as welcome changing requirements even late in development for the customer’s competitive advantage…

…Of course this is actually just Agile Principle #2. Yet ironically you will get hissed and booed for simply following the very agile methodology that the booers and hissers forced upon you...

…it ain’t easy.

I was introduced to scope creep with my very first project as a new, naïve, and innocent product manager. We were working on a meaningless feature for an even more meaningless customer. Back then I was dumb enough to think that my job was to solve market problems for the value of the business, so I suggested a simple addition to the feature that would make the product infinitely more valuable for all our customers instead of just this one narrow isolated use case.

“That’s scope creep,” I was told bluntly by the engineer working on the project.

And that pretty much ended the conversation.

When developers and scrum taskmasters utter the words “scope creep”, it’s like using a Jedi mind trick to convince product managers that the customers really don’t need that feature.

“These are not the features you are looking for,” they say as they wave their hands in a wiping motion across your face. “These are scope creep,” they wave their hand back the other way…

…you wonder what all the hand waving is about but somewhere deep inside you get a cold empty feeling in your heart as if you just realized you are indeed turning into a Sith Lord of the dark side, introducing evil and nefarious scope creep into an otherwise pure galaxy of blissful software utopia.

“Am I evil?” you ask yourself, repeating the words of a Diamond Head song. “I am man yes I am.”

Back then I didn’t even know what scope creep was. This was before I had memorized the entire encyclopedia of rote agile definitions, doctrine, and dogma. All I knew was that scope creep was bad and that this was a topic not open to discussion, akin to “he who must not be named” in Harry Potter…

…only “he who introduces scope creep” is a person considered to be much, much more sinister.

Sincerely, I’ve been living in fear of Scope Creep ever since that day with the same irrational fear that some have of a psychotic clown living in the rain sewers…

…if scope creep had a face, I’m sure it would look like Pennywise.

“I’m every nightmare you’ve ever had!”

Well.

Hopefully by this point I’ve convinced you that you are a disgusting creep in the community of software development and the only thing you have to contribute is scope creep, which makes you an evil, evil, son of a b*tch…

…it ain’t easy.

So here’s the lesson, and here’s how this is all going to play out for you.

The dev team is going to look at your backlog of thousands of items and commit to getting a project done by a certain date. Because they are terrible at estimating, they are going to completely fail at hitting that deadline. With this realization, it is now going to be your job to “reduce scope” in order to meet the time commitment…

…this will happen on every development initiative for the entire duration of your career in product management.

But here’s the twist you need to watch out for. The dev team is going to play mind games with you and try to convince you that the items you take out were actually just scope creep to begin with…

…oh the ingenuity of those sneaky bastards.

I mean, logically, if you are now willing to take those items out of the MVP in order to hit a launch date, then they must not be that important. In other words…

…you’re just really bad at your job and should have known better than to have ever added those features in the first place…

…Can’t you see the dev team all tapping their fingers together like Mr. Burns and saying in a mischievously manipulating voice, “Excellent”?

The team will also convince you that it is now your job to simply prioritize any future work that might be done on this stripped-down product…

..the word “iterate” gets thrown out a lot in these circumstances.

“We will just iterate on the MVP after we launch it,” the dev team tells you even though they have zero comprehension of how overpromised your roadmap is and that there simply isn’t any time to iterate on features they should have already built in their original commitment…

…at this point you make a perfect circle with the thumb and index finger of your right hand and explain to the dev in a perfect imitation of that Lord of the Rings guy, “One does not simply iterate on a product release.”...

…the organization is expecting you to move on to the next thing.

“Well, you set the priorities, so just decide what is most important you,” they tell you so nonchalantly that it fills you with all sorts of conflicting emotions of anger and humiliation…

…and that’s when you realize you’ve been had.

With craftiness and wizardry the dev team has just transferred their entire failure to deliver onto your shoulders. You now have the weight of deciding whether you are going to “iterate” and put your entire roadmap in jeopardy or just release a subpar application and move on.

“How did this just happen?” you ask yourself as your shoulders start to ache from holding up such a heavy burden...

...The dev team goes to the bar after work to celebrate their successful product release.

So what do we do?

What do we do?

Unfortunately, I haven’t figured out how not to be a creep in this business of product management. You will automatically be considered a creep no matter what you do … either holding people to their commitments … or introducing scope creep for mission critical items.

Having been a creep my entire career, here’s what I now do to help me navigate the spells and curses that the dev team witches and warlocks try to cast upon me. For any initiative, I clearly communicate to all stakeholders, developers, and engineering management, “The 3 Things That Matter”…

…and I force myself to stick to a list of only 3 things…

…because that’s all anybody can actually remember.

Many product managers fall into the trap of trying to communicate with backlog items, and story points, and burn downs, and blah blah blah.

“We have completed 4000 points out of 20 million,” you say at sprint review as if it is supposed to make any sense at all.

Trying to estimate and communicate a backlog of hundreds of work items and thousands of points fails every time. It always results in you becoming the creep.

So focus on The 3 Things That Matter. The 3 Things That Matter are just 3 high level business objectives. Then I make sure that everyone understands that the success of a given initiative is dependent on accomplishing those 3 things…

…or… if you only accept vocabulary that is defined within the rigid glossaries of scrum.org, I think they call this the “Product Goal” … and I’m sure they have an 80 page instruction guide on how to create a simple product goal along with a cult you can join to pledge your undying allegiance to scrum.

But whether you belong to a scrum cult or not, the most important aspect of a product manager’s job is to make sure you clearly communicate each sprint how the development work is progressing to achieve the 3 Things That Matter for your product.

It’s ultimately up to the team to figure out HOW to achieve those goals. This will give the team the flexibility to figure out their own scope creep as needed to accomplish the goals they committed to…

…and you don’t have to be such a creep.

And if they fail, well…

“It’s just 3 things guys,” you say. “You’re telling me you couldn’t figure out how to achieve 3 simple things.”

That’s right, who’s the ingenious sneaky bastard now…

Just remember that your job isn’t to deliver a list of story points by a deadline. Your job as a product manager is to create value and change the world. You do this by focusing on solving problems for users in your market and working with the team to achieve business outcomes.

Now go get the team to rally around The 3 Things That Matter…

…and creepy luck to you.