This is part of our ongoing series on Agile in Practice, which shares our journey learning to ship higher quality software faster. More related posts are available at the bottom of this one.

## Issue

With our insights related to [chunking big features up across multiple releases](/blog/release-in-chunks) and [solving release quality issues](/blog/release-quality-issues), our development and release cycles sped up a lot. After several cycles with great progress and very few bugs, our confidence grew. This led us to think bigger, which was a great thing. But paradoxically, as our ambitions grew, our pace of development started slow.

As we dug in to what was happening, we realized our increased confidence led to subtle behavioral shifts that decreased our pace of development.

Update meetings were turning into brainstorming sessions, rather than updates, and this was leading to bigger code changes. “While we’re doing this, why don’t we also . . . “ was a common phrase. As we generated more and more ideas, we’d try to sneak them into our current work. We were moving fast, after all, so we could make a few extra changes here and there. It should’ve been obvious that we were [forgetting learnings from our last experience](/blog/release-in-chunks), but overconfidence has a way of blinding people, us included.

It was good that we were humbled so quickly by slowing releases. Looking back at the behavior with more humility, we saw the underlying cause clearly: scope creep. Projects were expanding mostly because we felt so fast. But this expansion increased complexity, slowing our work and undermining the productivity gains we had made.

## Solution

We needed our discipline back. So we started to focus in on our behaviors. There were some common patterns that arose. Here are a few examples and the associated solutions.

### 1. Language That Signifies Scope Expansion

The number one phrase our team is: “While we’re doing this, why don’t we . . . ?”

This would be a dead giveaway if the person explicitly said, “ . . . why don’t we *also* . . .” with emphasis on the “*also”*. Because “also” means that we are explicitly expanding scope, we know what we’re dealing with. People usually omitted the “also”, so we had to pay close attention.

Other examples of the same type scope expanding language:

- “This is great, but could we . . .”
- “Wouldn’t it be cool if . . .”
- “While I was in there, I thought I should . . .”

Notice how all of these phrases could include the word “also” without any loss of meaning. That signifies scope expansion.

Call out the scope expansion and provide a place to document it for later.

Calling out the scope expansion would be enough to keep the pace of development moving, but sometimes really good ideas arise in scope expanding statements. People are excited to see or hear about functionality for the first time and they want to add to it. So we chose to capture ideas as they arose and set them aside. That way they were acknowledged and remembered, rather than simply dismissed as scope creep.

### 2. Unclear Ending Points Invite Scope Expansion

When a developer can’t describe clearly when they will be done with a project and what that ending point looks like, then the project is more likely to expand. It seems obvious when stated so clearly, but it’s tougher to detect in practice.

In the real world, everybody is trying to move quickly. So questions don’t always get asked and answered. When people do ask questions, it’s sometimes uncomfortable to put someone on the spot with a pointed question. It’s especially uncomfortable when you think they might struggle to answer. But there are ways to deal with these issues.

Even if it’s uncomfortable, the team has to ask clear questions, which are:

- When will this be done?
- What will this look like when it’s done?

Then wait for a response. If the lead can describe what done looks like in a way that you can understand, and their timeline is in the right ballpark, then the project will finish close to the given timeline. If they cannot describe the finish line, or their timeline is way off (especially on the short side, paradoxically) that’s an issue. If they waffle a lot, then the project is probably too big and needs to be chunked up.

Note that these questions are very different from the leading questions:

- Will this be done by XYZ date?
- Do you know what needs to be done to finish this project?

These two questions are yes/no answers and the answers will generally be “yes” to both, because that seems like the acceptable pair of answers.

### 3. Leadership Suggestions Are Interpreted as Scope Expansion

Executives - especially those with Director, VP or C in their titles - will often offer suggestions. Sometimes this can be helpful, like if the team is stuck. It gets them unstuck. Other times, it can be unhelpful, like if the team is just about to finish something. We’re going to talk about the second situation here.

The leadership coach Marshall Goldsmith has a great saying about this. He says for leaders, “suggestions become orders.” And that happens whether you want it to or not.

So imagine that a team member is basically done with a first version of a project, and they’re talking about it in an update meeting. Then somebody with a C in their title says, “Wow that’s great, and it’ll be especially awesome when this one extra thing is added.”

The team member’s focus shifts immediately from “Wow that’s great!” - which is what the exec probably intended to say - to “especially awesome when this one extra thing is added.” The executive just subtly redefined done to mean when that extra thing is added. It’s a scope expansion, whether it was intended to be or not.

The reason this one is hard to solve is that it requires one of two things:

1. Executives need to exercise restraint, or
2. Team members need to (somewhat) disregard what executives say

We’ll come out and say Option 1 is easiest if it’s possible, but sometimes there is an executive that can’t reign it in. In that case Option 2 is the only option.

Organizations deal with Option 2 in many ways. The most common is to put a buffer - usually a product manager or engineering leader in between the executive and the people who are doing the work. Sometimes teams manage through language - the executive has to explicitly say that something is required before launch. Sometimes the language is even tied together with a cooldown period - the executive needs to wait 24 hours and come to the same conclusion that something is required for the team to move on it. As long as the executive buys into the process, it can work.

### 4. Some Team Members Bias Toward Scope Expansion

This is a more subtle version of scope expansion than executive suggestions, but it’s in the same vein. Some team members have a natural desire to make projects bigger. They want to see the whole vision executed, which is excellent. Their natural bias is to try to do more, which is helpful much of the time.

Sometimes, though, these team members take a simple project and make it complicated. Possible reasons for this are many. Maybe they want to do something big, so when asked to do something small, they try to do something big anyway. Maybe they are super confident and think they can finish more than they can in a given time horizon (and maybe they’ve even done that in the past). This type of complication isn’t an issue until it is.

When it becomes an issue, it’s generally because the team needed something done to keep moving ahead as a team. The individual, with all the best intentions, quietly expands the scope of their portion of the project, but fails to:

1. Finish the thing the team was relying upon first, or
2. Communicate the expansion to the team

As a result, the whole team is surprised one day to learn that their collective work is on hold until the thing the team was waiting on is done.

There are two ways of looking at this issue. The first way is to call it a team member issue, and to ask them to change their ways. The second way of looking at it is to call it a management issue.

We tend to believe that the more it happens, the more it’s a management issue. The first time a team member does something like this, we can say the team member should’ve communicated better. The second time that team member does something similar, it’s still mostly on them, but the manager should have been paying attention. The *third* time, the responsibility for the miss is definitely on the manager.

It’s a manager’s responsibility to notice patterns of behavior and to make the most of them. If the highly motivated team member is constantly trying to *do more*, then the manager has to figure out a way to channel that productivity. The team member should be able to at least do less (what the team needs) in less time first, and then do more. Or they should be asked for specific updates daily, especially when a project is taking too long, so nothing comes as a surprise.

In other words, once there is a clear behavioral pattern within the team, the manager has to find a way to manage the pattern.

## Results

The four patterns above all showed up in our processes from time to time. Some were more significant than others. As we learned (and continue to learn) to catch them and address them, we re-instilled discipline into our practices.

We now recognize who on our team has which biases, who can help to support each other with scope definition, etc. and how to call each other out when scope expansion occurs. We don’t do it perfectly, but we do it pretty well. And we’ve moved back to one-to-two times per week release schedule that always contains something meaningful to end users.


Dealing with scope creep

Related posts

Top 3 reasons custom software projects fail

Release big stuff in chunks

Dealing with scope creep