One thing that drives me crazy about the agile world is the incredible prevalence of semantically overloaded terminology. Simply put, semantic overload is a word that has different meanings in different contexts. The problem with this is that it can create confusion. For example, if I tell you that I’m going to run to the store, you don’t actually know if I’m going to drive or jog. You might assume one or the other. You might make some inferences based on context or past history. But you don’t know.

Now, “running to the store” probably rarely leads to confusion. You probably do figure that one out based on your knowledge of the person you’re talking to, how far away the store is, etc.. But agile software development is still relatively young, enough so that a commonly held understanding of the vocabulary hasn’t been well established yet. Let’s talk about a few of the major offenders.*

Agile

Even the term “agile” itself is overloaded. When we talk about agile, even in the context of people who really care about agile, we often mix up the concepts of “doing agile” and “being agile.” This opens us up to tons of unnecessary confusion. We could just as easily talk about being agile and doing Scrum or XP, or DSDM, or whatever your favorite framework is.

Inspect and Adapt

Agile coaches and Scrum Masters often talk about “inspect and adapt” in the context of workflow. It’s not surprising given that this type of inspection and adaptation is built right into the Twelve Principles behind the Agile Manifesto. We should also recognize that inspecting and adapting our product is a presumption of Agile values and principles. “Customer collaboration over contract negotiation” and “responding to change over following a plan” are in the manifesto because we recognize that we can’t know what the end product should look like until we have it, or at least a portion of it, and we’ll need to modify our product once we see how people interact with it.

Scrum

This is the one that bothers me the most on this list. Scrum is both a framework and a daily meeting within that framework. Honestly, this one is kind of ridiculous. The daily stand up meeting is a regular part of many workflows, even outside of software development. Calling it a “daily scrum” for no apparent reason is just confusing. It would be fine if people would consistently use the phrase “daily scrum,” but people like to shorten things and often refer to this meeting simply as “scrum.” I generally refer to this meeting as stand up because it avoids all that confusion.

As Agile ideas and practices continue to develop it’s important that we conscientiously talk about these ideas and ways of working. We must keep in mind that we may hear a word and assign it one meaning, but that the speaker might have something else in mind. And vice versa. This means we might need to pause once in a while, clarify what we’re talking about, and carry on with our conversation. It’s a moment well spent if it saves us from revisiting an entire conversation because we didn’t clarify our terms at the beginning.

* I’m only mentioning the ones that bother me the most right now. There are certainly others.