I was a pup of a programmer back in 1980. I was working at Sperry Univac (yes, Univac). I recall as if it was yesterday, a grizzled project manager came up to me as I was about to add a feature to the mainframe (yes, Mainframe) software I was working on.

Bob, he asked, why are you adding that feature to the I/O Sub-system? It isn’t part of the requirements nor is it part of the plan. Don’t you know about Scope Creep he asked? No, I said, I hadn’t heard of that concept.

He sat me down and began to put the fear of God in me with respect to Scope Creep. He said that it:

• Was one of the primary contributing factors to all failed projects;
• Was a stakeholders way of getting ‘free’ work done;
• Was instrumental in making programmers work overtime;
• And most importantly, it was his job to prevent it from occurring.

He said to immediately stop working on the feature and let him negotiate whether it made sense or not. I walked away from the encounter starry eyed and appreciative of my project manager. I also had a new-found wariness for scope creep in its many forms. I vowed that I’d be much more vigilant in the future against this terrible enemy.

Fast Forward a Bit…

I was introduced to the agile methods in the late 90’s. It was an introduction to the Agile Manifesto, agile principles, Scrum and Extreme Programming that very much intrigued me. They were a very different way of handling many aspects of software projects. With respect to change and scope creep, their advice was contrary to my teaching. They invited us to embrace change to the advantage of the customer—letting the customer make late-binding decisions whenever they were responsibly possible.

I remember flashing back to my project manager from Sperry Univac and it took me quite a while to come to grips with agile change management. He had taught me well it seemed.

How does Agile “handle” Scope Changes?

Let’s start with a reference from the Agile Manifesto and it’s underlying principles for general guidance. From the Manifesto there are two of the four base principles apply to scope changes:

Customer collaboration over contract negotiation
Responding to change over following a plan

And the following two principles behind the Manifesto also apply to scope changes:

1. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
2. The best architectures, requirements, and designs emerge from self-organizing teams.

Responsible Moments

In my coaching I often speak about responsibility when it comes to change management. For example, it is irresponsible for stakeholders to try and change content in the end games of most projects. However, early on in the discovery phases, it might be the most responsible thing they could do. So the timing of change certainly matters.

Also, continuously changing things isn’t responsible; instead it’s chaos. Technical teams are an incredibly valuable resource in most organizations, so stakeholders need to change scope and direction with care. It needs to “make sense” to the team and they need to “see” the benefit.  So, selling the rationale behind the change truly matters—so that teams can buy-into the changes.

Embracing Change

I coach agile teams to embrace responsible change. To allow the customer, normally a Product Owner in Scrum terms, to ‘drive’ the teams’ focus. That as long as the Product Owner represents the best interests of the business and customers, the team needs to try and be as adaptive as possible.

And what about change trade-offs? Well, there are no free rides in the agile methods. If a stakeholder changes their mind, I fully expect them subtract as well as add or change scope. The team has a fixed velocity and, if there’s a fixed date, then they’ll normally have to remove an equal or greater amount of work. That happens in construction projects and it should happen on software projects.

The advantage in agile projects is that the team makes everything transparent—their backlog of work, the sizes of the backlog elements, their velocity, their current progress towards any release plans; EVERYTHING. There is no padding in either direction.  This fosters integrity and honest between the team and the stakeholder when changing scope.

Emergent Understanding

Finally, one of the key underlying drivers for scope change is not from outside stakeholders, but by the internal explorations and ongoing understanding of the problem space by the team. The agile methods are an “emergent process”. They don’t even try to get things right up-front in technically complex systems development.

Instead things like design, architecture, and technical tradeoff decisions occur largely on-the-fly as challenges are discovered and solutions created. In agile terms, this is referred to as “emergent everything”—as understanding unfolds for a team as they actually learn as the implementation proceeds. This happens in all software projects, whether we acknowledge it or not—as we rarely know everything in advance.

The distinct advantage of the agile methods is that they wrap this emergence in an iterative envelope, which allows the team (and the stakeholders) to react to new learning.

Wrapping Up

I have to give credit to my inspiration for this article as it came from the PMI Post here:

While I may have exaggerated in this article, more for theatrical intent than anything else, I am strongly opinionated about this point. The article’s title is what intrigued me. If you read the content, the author takes a much more measured stand on scope creep. But the title harkened me back to my days at Sperry.

It also forced me to want to respond. I’ve learned the hard way that you shouldn’t fight, control, document, resist, or even tolerate Scope Creep. Responsibly embracing it to your customers’ advantage is truly the way to go.

Stay agile my friends,

Bob.