Words don’t mean what they don’t mean

<rant>

Words don’t have firm, unambiguous, unchanging meanings. This is a source of some frustration for me. The same word can have multiple meanings. Sometimes there are context-dependent meanings. Sometimes there are shades of meaning conveyed by tone of voice. People can have multiple interpretations of the same basic meaning of any given word. Clear communication is more challenging than it might appear to be.

In the field of software development, we have an unfortunate habit of re-using old words to represent new concepts. Maybe it’s because we value re-use (whatever that means). The English word, agile already had a meaning before software developers came along and started using it for something else. A ballerina is agile. A faun is agile. That’s easy to understand. Now, software development can be agile, too (whatever that means).

Velocity is a vector quantity comprising speed and direction. That’s easy to understand. But now it’s also a software development metric, and one that doesn’t seem to be used in the same way by any two development teams. Those are only two examples among many.

There is hope, though. If we can’t be certain exactly what a word does mean, we can at least be pretty certain of what it doesn’t mean. We can be reasonably sure the word sideways doesn’t refer to a type of mayonnaise. We can be reaonsably sure the word yesterday is not a synonym for orange — neither the color nor the fruit.

As long as we’re rigorous about using words appropriately within a given context, we stand a fair chance of avoiding confusion. So, we only have to insist on consistent, unambiguous word meanings within a context. The same words in other contexts can represent other concepts altogether.

Well, I guess there’s no problem, then. That’s a relief. Whew!

Unless…

Unless people aren’t rigorous about using words appropriately in context. That would sort of mess things up, wouldn’t it?

Or would it? Who cares how people use words, anyway? As long as they’re happy with what they’re doing, let them use any words they please. Let them spread sideways on their sandwich, and have a juicy yesterday for dessert. What’s the problem?

The problem has to do with carbon monoxide poisoning, obviously.

The way carbon monoxide poisoning works is that carbon monoxide molecules attach to receptor sites for oxygen. Then, when the organism inhales, there’s no place for oxygen molecules to attach. Carbon monoxide molecules don’t easily unattach from the receptor sites, so if the organism doesn’t get away from the source of carbon monoxide pretty quickly, it could die.

Humans use words to represent concepts. When a person co-opts a word to represent a concept other than the one it really represents, then there is no place for the original concept to attach to the person’s mind. If the person doesn’t get away from the corrupted definition quicky, he/she could make the proper concept unavailable to him/herself.

Example 1: Collaboration

From The Free Dictionary:

col·lab·o·rate intr.v. 1. To work together, especially in a joint intellectual effort.

collaboration n 1. (often foll by on, with, etc.) the act of working with another or others on a joint project

In software development, collaboration often means that team members who have different professional specialties work directly together to add value to the product or to solve problems, or that different team work jointly to add value or solve problems. It specifically means that different workers or different teams do not hand off artifacts that are developed independently and passed along through a series of linear steps.

On a process improvement engagement, while working with several client personnel with a goal of understanding and mapping their current-state delivery process, I noticed there was a sequence of three steps in the process whose interaction was unclear to me. Group A would create an artifact and hand it off to group B. In between there was another step, labeled “collaboration.”

I questioned this, as there is no need for a formal process step to denote collaboration when collaboration is the normal mode of work. In fact, real collaboration is not a “step” at all; it’s a style of work.

It was explained to me that in the “happy path” version of the delivery process, the collaboration step did not occur. The hand-off from group A to group B happened once, and the work proceeded serially. When group B could not work with the artifact they received from group A, then they would “collaborate;” that is, group B would throw the artifact back over the wall and tell group A to fix it.

The fact they had defined a formal step in their work flow to deal with this situation suggested to me that it occurred frequently. They confirmed this. It happened more often than not. There are a couple of problems with addressing the problem in the way they did.

First, the fact the back-flow was so frequent that people began to think of it as a distinct step in its own right indicated there was an underlying systemic problem. Maybe the steps carried out by groups A and B were happening in the wrong order. Maybe the artifact wasn’t in proper condition for group A to do its part correctly, and the underlying problem was upstream of group A. Maybe group A just didn’t know how to do its part correctly. Maybe group B didn’t understand how to advance the product from the point where they received the hand-off from group A. Maybe they hadn’t defined clear enough policies for advancing the work from group A to group B. Any number of root causes were possible. However, as long as the working groups treated the situation as “normal” by defining the re-work as a distinct step in the process, they were hiding the fact it was a problem. When people don’t see a problem (or they don’t see it as a problem), of course they don’t think about solving it.

Second — and this is where the bit about word meanings comes into play — it is very possible that true collaboration would have helped groups A and B in this case. Root cause analysis might have suggested collaboration as one possible remedy. However, as long as the word “collaboration” stood in for the concept of “re-work,” there was no receptor site available in the people’s minds to which the proper concept of “collaboration” could attach. Yes, they could feel good about themselves by labeling the re-work with a happier word, but by doing so they blocked their own path to process improvement. A back-flow is a work-around for some other problem; it alleviates a symptom, but doesn’t cure the illness. What these people had done was to institutionalize a work-around instead of looking for the true root cause(s). They set the trap for themselves when they corrupted the meaning of the word, “collaboration.”

Example 2: Velocity

On a different engagement, I was working with another coach to introduce “agile” methods to a mid-sized company. A couple of teams were learning to use Scrum. One day, I noticed something on one team’s release burndown chart that appeared anomalous to me.

Like most burn charts, this one was a line graph with one line showing the planned performance of the team and another line showing the observed velocity plus a linear trend line, indicating the projected performance of the team. There was a gap between the two, and the gap was gradually increasing. At some point in the future, the “actual” trend line suddenly took a hard turn to starboard and joined up with the “planned” line.

I asked the other coach how she had come up with this. She said that in order to meet the project plan, the team would have to “do something” to make their actual performance align with planned performance.

Okay, so what was the mechanism that would cause that sudden right turn on the burn chart?

The team will just have to increase their velocity.

Okay, how will they do that? What is the mechanism by which this will occur abruptly, on that date four months from today?

Teams always get better as they go along.

Okay, but the chart doesn’t show a team getting better as they go along; it shows a team suddenly quadrupling its velocity, and then just as suddenly reverting to its normal velocity. So what exactly will this particular team do between today and the date shown on the chart that will cause this to happen?

They will have to figure something out. They’re a self-organizing team, after all.

I don’t know how to generate a linear trend line that behaves like that. Clearly, this chart doesn’t show a projection of the team’s actual performance. That future correction must be hand-drawn. What are we really tracking here?

In order to meet management’s defined delivery date, the team has to produce a set number of story points per sprint. We’re tracking the percentage of total story points that they have completed to date. That’s their velocity.

Um, well, no, that’s not what velocity means. What we’re tracking here is “percentage of scope complete to date.”

You know that, and I know that; but management wants to call it “velocity” because they are trying to be “agile.”

Aren’t we here to educate them about these things?

They aren’t interested in that. They’re interested in delivering all features on schedule and on budget, while sounding cool.

Sounding cool is irrelevant. If they need to track percentage complete, it’s okay to do so. Why don’t we just call it what it is?

Because they want to call it “velocity.”

I understand. But if they call “percentage complete” velocity, what will they call velocity when they reach the level of maturity with “agile” that they’re ready to use it properly? How will they even know they ought to be thinking about getting to that point?

You’re being too philosophical. The client wants to call it “velocity,” so it’s “velocity.” Do you have some objection to making money?

This is another example of blocking one’s path to process improvement by corrupting the meaning of a word. When this organization reached the point that they were ready to practice adaptive development, there would be no receptor site available in the people’s minds to which the proper concept of “velocity” could attach. They would have no physical mechanism in their brains to understand the concept of “velocity.” It would always mean, and could only mean, “percentage complete.”

Words

Those are only two examples of a phenomenon I see very often. I’m sure you’ve seen it, too. I don’t think people are doing themselves a favor when they redefine terms in ways that block their own ability to consider new concepts and different perspectives.

Human language constantly changes. Many of the words we use today would make no sense to Shakespeare, and we need scholarly annotations of his works to understand the words he heard and used every day. This is normal.

However, in the narrow context of software development work, we are well served by sticking to the standard definitions of terms that denote specific methods, practices, or techniques. When we redefine words just to feel good about whatever we happen to be doing, we deny ourselves basic reasoning tools that we need to achieve improvement.

</rant>