Take 3, Scene 16: The Truth Behind Scope Creep

On this episode of Take 3, we discuss the notion of scope creep – what it means for development teams and whether it exists at all. Jessica Hall and Adam Hahn join us in the studio today to continue the discussion of this topic, which was started by Jessica Hall in her article – “Scope Creep or Just Change?” – published on Mind the Product.

Episode Highlights

• Jessica expands on her article from Mind the Product by discussing the common misconceptions behind scope creep and why teams are usually ambivalent towards it
• Adam and Jessica talk about the reasons teams run into problems when it comes to scope creep and offer suggestions on how to work around it
• The two of them share what they’ve learned from working through this issue with their respective teams

About the Guests

Jessica Hall leads the product and UX teams at 3Pillar Global. She helps clients from startups to enterprises build great products by defining their vision, focusing development efforts, and engaging with customers.

Adam Hahn is the Executive Director of Engineering at 3Pillar Global. He leads the global engineering team to deliver great products for our clients, whether they’re built in India, Romania, or the US.

Read the Transcription

Julia Slattery: so let’s start with the basics. What is scope creep?

Adam Hahn: So in software development projects, and probably projects anywhere, the idea of scope creep is where you have requirements that are not understood at the beginning of the project that then are discovered along the way. These can be things that come as a result of the development work that happens, or something changes in the environment of the project. So maybe something in the business market changes, or a competitor changes something, or just something that’s discovered at the business.

But the idea is that when a project started, you had a good sense for what features would be required and how long it would take to get that done and what the effort would be, and the idea is that as new things are discovered, that’s scope creep. It uses that terminology, where you get the idea of some monster, or some creature that’s creeping along and it’s making things harder for the team. But it’s the idea of expanding scope, in a nutshell.

Jessica Hall: You can also think about it as if you were to do a home renovation project or watch some home renovation show, and all of the sudden, midway through the project, they ask for something that you’ve never heard of before, and all of the sudden it makes it more complicated and more expensive to get something done on time. That’s also scope creep, but just in a different venue.

Julia Slattery: Jessica, you recently published an article on this topic and essentially said that scope creep was a positive for teams. Can you elaborate on this a bit?

Jessica Hall: I wouldn’t say it’s a positive so much as I would say there is no such thing as scope creep in product development or software development. It doesn’t exist, really, in our world, because we don’t know everything that we really need to build when we get started, and we don’t know everything about how we’re going to build it. It’s a situation that is constantly evolving and constantly changing, and I think scope creep speaks to everything that’s negative about the process. This actually started when we were doing a training on what we call the “product mindset,” and one of the core tenets of the product mindset is being able to excel at change, and people said,” Well, what about scope creep?” And our argument was that scope creep is just change managed badly.

What we really wanted to talk about is that when these new ideas and these new things are learned through the process, some of them are gonna make the difference between a great product that is really successful, and a product that underperforms or should have come out a couple years ago, because it’s really not meeting today’s needs. And what happens is teams see these outside requests or these inside requests as the enemy, instead of as an opportunity to make something really great. So what we wanted to be able to do is talk people about, yeah, we’re gonna have change. We’re gonna learn as we go. The most important thing is that we manage this learning and these new ideas well, so we can take advantage of them rather than having a bunch of horrible, nasty things happen that mean that we don’t miss a release date, or it costs too much money, or we have the wrong features.

Adam Hahn: I really think that scope creep is kind of a holdover to waterfall methodologies, and to that mindset where, you know, you have this phase at the beginning where you decide everything that’s getting done in a project, and then you go and execute on it, and you build the project and get it done. Whereas what we found, and what we practice at 3Pillar is, using the agile and lean methodologies so that you are figuring out what the right thing to do is at each step in the plan. So you do have scheduled releases. You can say, “We’re going to have something that’s going out at this point,” but for you to be able to engage in that process of discovery and learning as you’re going really, as Jessica said, helps you build a great product, right? It helps you build something that is exactly what you need in the market.

So, to Jess’ point, it’s fantastic that this is scope creep. As I was saying, it’s kind of a big, ugly, scary word for something that shouldn’t be ugly and scary. It should be a part of how you do things.

Julia Slattery: So why do most teams find this to be a hang up?

Adam Hahn: So again, I think this goes back to some of the old ways of doing things in waterfall methodologies. Really what it comes down to is, when you are effectively using agile development practices, and you are effectively developing software in small units,  in self-contained chunks, in an iteration, you have to be very rigorous about making sure that what you do in an iteration actually gets done in that iteration, so that you can then turn your attention to something else.

And this is, I think, the fundamental cause of that stress, because if you don’t have a team that can accurately define what it means to be done with some unit of work in an iteration — so something that is a feature that’s complete, that faces an end-user that they can see, it has its internal test. It has its external test. Something that is complete enough that at the end of an iteration, you can then go and change direction completely, work on something that you had no idea what it was at the beginning of this iteration. Next iteration, you can work on something totally different.

So if teams aren’t operating that way, then it becomes very difficult to move in a new direction, because there’s always some holdover work that has to happen. We often hear, when we’re working with teams that are not doing great at this, “Well, it’s done, but it’s not tested.” And, you know, that’s why it’s so critical to have a good definition of what it means to be done, because if something’s done but not tested, that means that your test engineers have to be focused on that, and if test engineers are working on something, and they’re doing a good job, it means they’re gonna find problems, and there’s gonna be something that has to get addressed, which means the developers are gonna have to work on it again.

So, again, if we have a good process running, where a team can complete something and know that it’s ready to ship to a customer, then, if something changes, or if there are new requirements or anything like that, they have that ability to go and just say, “Great. This is what’s next most important. I’m gonna do this.” So addressing that is really the key here.

Jessica Hall: I think there’s some underlying frustration that needs to be dealt with. The team has some frustration, because they feel like the finish line is always being moved. There’s just a little bit more to do, a little bit more here, a little bit more there, and that they’re trying to manage all of these inbound requests that are messing up how they’re trying to get things done, and the leadership has a different set of frustrations.

The leadership feels like the team is being overly rigid, and they’re not being responsive, and their frustrated because they don’t see a team adapting to what’s happening in the marketplace, or with the customers. And so you’ve got a lot of people really upset because change happens no matter what, and some people are dealing with that and managing it day-to-day, and other people aren’t, and the folks who aren’t in a position to be able to deal with it are going to be very frustrated, they’re going to not be able to get things done, they’re going to have a lot of half-finished crap. So, what we’re talking about is how do we make this process work and be effective for the team and the leadership?

Julia Slattery: So how do you suggest that teams reframe their mindset to work around, or even with, scope creep?

Jessica Hall: I think it starts with accepting the unknown, and accepting that we can’t control everything, which for a lot of people is kind of challenging. So once you accept that we don’t know everything we’re going to do, things are gonna change along the way, and that we have a method for changing them, life gets a lot easier, and it’s a tradeoff. You’re going to give up control, and on the backend, you’re going to get flexibility. You’re going to get the ability to, if there’s a fire drill and you have to respond to it, you can do it without blowing everything up.

It also requires a couple of other things from you. You need a way to collect ideas that doesn’t disrupt day-to-day operations. If your team is constantly fielding requests from every department and they don’t have dedicated time to do their work, that’s going to cause a lot of frustration and we’re not gonna be able to shift working software. So, you have to have a way to collect it, and then you have to have regularly scheduled time to go through it, to validate that it’s really a good idea, how you might solve the problem and how important it is to do this. Doing that in a regular scheduled way means that we’re being responsive without being disruptive.

Then you’re able to communicate back out to the larger organization, “Okay, here’s what we’ve decided. Here’s what the next couple of releases looks like,” and everyone can see what’s happening. It’s a process that’s regularly scheduled so it doesn’t cause disruption. It’s focused on prioritizing those things that are most important for our end customer and for the business itself, and it communicates to the rest of the organization, “Here’s the plan, and here’s what we’re doing.” That really allows us to deal with all of these changes in a productive way, and create something that’s really going to align with one of our other product mindset principles, which is build for outcomes.

Adam Hahn: Yeah, and that ties back very well into working with agile methodologies, because when you are developing things in a short, iterative methodology, then that allows you to be able to take these changes well, and get the team fully on board with that. The team then understands that by having these refinements, by being able to discover these things, and having that go into the planning process for releases means that they’re going to be building a better product at the end of the day. So really, engineers love it when their software is delivered into the public and people are using the applications that they’ve written. So, making sure that they understand that this is how we get to a very successful product helps to get folks to embrace it.

Jessica Hall: So we really want to welcome all the great ideas from our customers, from the sales team, from the marketing team, from the support folks – we want to welcome everybody into the process of creating this product, but let’s just do it in a way that doesn’t make us all crazy, and let’s do it in a way that means that the most important problems, or the best opportunities are taken advantage of. And that’s what we advocate. So, we’re telling our teams about this, or I make a grumpy face if you say scope creep in front of me, and then I go on my whole spiel about why I think there is no such thing. Put it to the side and deal with what’s in front of you.

Julia Slattery: So, what have you learned from working with clients or your own teams about this process?

Jessica Hall: So, in the last eight months, we’ve learned that the single-most consistent predictor of client satisfaction on new accounts is something called release planning. If the client can see what features are going to get released when, and they can see that within two weeks, you can just see the weight come off their shoulders. They can communicate what’s going to happen to other people in their organizations, and they have more trust and confidence in the team that they’re working with, because they can see, “These are all the things I want get done. These are the sizes of those things, and this is when stuff is going to get done.”

And the next time somebody says, internal to the team, external to the team, “Hey, I’d really like this thing,” we sit down, we pull the release plan out, and we say, “Okay, what thing that’s about the same size is gonna shift to the right?” And all of the sudden, all of that mish-mash and stress and negotiation that happens between people in organizations about what’s going to get released when – that stress just goes away. It’s really simple. There are 40 things here that can fit. If you want something else in here, you take something else out, and we have a conversation about what that is, and it becomes remarkably simple.

It creates so much trust and confidence in the team when you have what we call “release planning” done. It’s not a roadmap that’s six months, a year, two years, five years down the road. It’s, “Here’s what’s going to happen in the next couple of months so you can feel pretty confident it’s going get done.” I’m telling you, you can see that weight just come off of their shoulders, that they feel like, “Oh, okay, I trust you and I have more confidence in the team because of it.”

Adam Hahn: It’s a fantastic process that our teams go through with our clients. Because this is a collaborative process, where we are as a team, coming up with what the right answer is for what becomes the priority, and what is de-prioritized. It equips our clients to be able to say, when they’re going back to their business stakeholders about something moving, “Oh, well, we decided that because this thing here was more important, we were going to move something else out over there.” That process, where they can say, “Oh, here’s how we came to this,” and can effectively communicate that with their stakeholders, that’s part of that weight lifting off of them.

I’ve seen it in the past, where an engineering team would – sometimes supported by project management or sometimes on their own – make decisions about prioritization of things, but not in a collaborative process with the stakeholders. That just increases the stress of the stakeholders because then it feels like a promise isn’t kept, or a commitment isn’t lived up to. But because we do this in a collaborative way, and we do it in partnership with our clients, they know what’s going on there, and to Jess’s point, that does help increase trust when we can say, “Look, okay, I totally get it. That’s the most important thing to you now. We think it’s going to take this much work. Let’s figure out where it fits in, and what it does to the release schedule, and how we can move that around.” And we found that by having those conversations where we worked very closely to discuss what’s important and how we’re going to get there, it helps us build great software for our clients.

Jessica Hall: Trust, transparency. Those things make for a great relationship between the software development team and the whole rest of the company.