Names Remove Impediments

Words mean things to people, and quite often, they don’t mean what the dictionary would lead us to believe. Words have cultural connotations. They have associations from our past. When we use those words, no matter what carefully crafted notion we intend that they mean, our listeners hear something different, something more, something less.

Often – most days I think usually – the impediments we find in our work involve other people. To remove those impediments, we need to communicate with those people. Unfortunately, unless we are really good at interpretive dance, we must use words to do this. Let’s consider some possible impediments one might encounter and what we might do about them. I’ll title each section with a few words that are related to the impediment.

Project Manager

In pre-Agile software development, the Project Manager has historically had a very wide-ranging role. Depending on the situation, they might allocate resources, they might interface and negotiate with the customer, they might assign work, they might schedule or reschedule work, they might be responsible for profit and loss, and so on. Depending on the organization you visited, you would find a very broad selection of individuals and responsibilities.

Agile thinking, at its base, asks us to use a very different model of running a project. Agile asks us to have a self-organizing team building the product. It asks us to have that team interact with its customer, ideally a real end user customer, but at least a business-side person with real accountability for maximizing the return.

Often in our classes, Chet and I will ask the team to brainstorm all the responsibilities that might go under role names like “Manager” and “Project Manager”. Then we ask them to say where, in an Agile situation, those responsibilities are handled. Many of the things that a Manager or Project Manager used to do are now done directly by the team, or the development sub-team. Many are done by the accountable business person. Many of them seem to be related to some coaching activity. Some of them, like setting budgets or team size, turn out to have no defined place in Agile. Most of them, however, do have a defined place, and that place is emphatically not in “Manager” or “Project Manager”.

Agile changes responsibilities and accountability around in a very profound fashion, compared to what people have done before. If Agile used the terms “Manager” or “Project Manager” as Agile “Terms of Art”, the definitions of those terms would be profoundly different from what people are used to.

The result would be that we’d say the words “Project Manager”, meaning our shiny new thing, and they’d hear “Project Manager”, meaning that same old thing that they already knew about. They’d think “yeah, got it”, but no, they don’t got it at all.

So Agile methods and frameworks generally do not refer to old-style role names at all. They make up new names, to embody the new allocation of responsibility and authority.

This is not “doing the wrong thing because of an impediment”. It is removing the impediment by removing the ground upon which the impediment stands.

Commitment

The word “commitment” is heavily loaded. We make a commitment to love, honor, and [optionally] obey. This is supposed to be a lifetime promise, never to be broken. If we deviate from that promise very far at all, we can expect big trouble.

In business, commitment should probably mean something like “We’ll try really hard and get back to you in a timely fashion if things don’t look good.” But to many people in management commitment means something more like “You promised to do this. If you do not do this, you broke your promise. I should kill you for that, but probably I’ll just torture you a lot.”

For a long time, the Scrum Guide used the word “commitment”, saying that in Sprint Planning, the team “commits” to the Sprint Goal (and in practice, to get the chosen backlog items done). The word turned out to be problematic, and this was inevitable. Frankly, it is surprising that the word lasted as long as it did.

Scrum, like most Agile frameworks, uses a time box to provide visibility into what’s going on. In every time box, we build an increment of software which can be inspected to see how things are going. Naturally, at the beginning of the time box, we decide how much work to take on. Because we intend to do our best to get that much work done, Scrum used to say we “commit” to it, meaning that the team looks each other in the eyes, and decides, yes, we can do this.

But producing a software increment containing N backlog items is inherently a stochastic process. It is a random process. Sometimes you’ll get N. Sometimes you’ll get fewer than N. Sometimes – oddly rarely – you’ll get more. The team cannot possibly know how many they’ll get done. Things inevitably happen.

While doing Scrum, teams habitually misunderstood the notion of “commitment” that Scrum had in mind. The commitment to the Sprint Goal, to being “Done”, to building good software – all those ideas were internal, the commitment of the team to itself. But management uses the word to mean “You promised to do this. If you break your promise, we’ll torture you.”

The team will respond to this attitude in a couple of very simple ways. First, they will take on less and less work, so as to minimize the chance of being waterboarded¹ at the Sprint Review and Retrospective. Second, they’ll adjust the amount of testing and design refactoring they do, again to minimze their chances of a meeting with Dick Cheney and his staff of people with just a few questions².

The almost inevitable result of this is that less and less gets done, and it gets done less and less well.

All because of a word? Not entirely, but the word is visibly implicated.

This is an impediment to successful Scrum, and it was written right down in the Scrum Guide. What to do?

One possibility was to redefine “commitment”, or explain it in great detail, so that from now on when people heard the word in a Scrum context, they would no longer think “promise”, but instead think “dedication” or some better thing.

The choice that the authors of the Scrum Guide made was different. They removed the word that had ineffective connotations, and replaced it with words that better communicated what they had meant all along.

This is not “doing the wrong thing because of an impediment”. It is removing the impediment by removing the ground upon which the impediment stands.

Summary

Agile replaces the idea of the Project Manager and their responsibilities with new ideas. It would make no sense to keep the term with a new meaning, since listeners would continue to have the old connotations. So Scrum, in addition to re-allocating the responsibilities, names the roles that include the new collection with new names, Product Owner, and ScrumMaster.

Agile replaces the idea of “a commitment is a promise” with ideas around forecasting and team responsibility. It chooses words that better mean what it is trying to communicate.

TL;DR

Agile renames things because the old words themselves are the impediment. The ideas remove the impediment, and the words help ensure that the listener understands that it’s not just the same old stuff.

This is not “doing the wrong thing because of an impediment”. It is removing the impediment by removing the ground upon which the impediment stands.