A part of my job is to debate with people about agile software development, sometimes, just analyzing discussions without taking part in it. I noticed one major factor that leads to arguments: misunderstanding. Two people may not agree on something only because they are simply not talking about the same thing, even though they are using the same words! In fact, words correspond to very different concepts or experiences in people. When the description is made using something that is unknown to us, we will first try, consciously or unconsciously, to link its properties to what we are already familiar with, and not necessarily take the required step back to interpret it globally by disregarding our existing knowledge. This understanding of things is partially or totally dependent on the subjective perception of the participants in a discussion. These perceptions are largely molded by the different cognitive biases that interact, self-reinforce. In psychology, we speak of heuristics in judgment. All of this can become very problematic in the context of so-called “psychological contracts,” where complexity emerges from these variable perceptions because of the positive (or negative) behavioral loops that become impossible to solve.

The debates can take long hours before we actually notice the problem, but in many cases, it remains unnoticed and everyone leaves with his or her beliefs and nothing changes. The fact that this article (and many others) exist is the consequence that there is widespread confusion caused by the creation of new terms to define similar (or existing) roles or behaviors. For example, the term “Carnism” or “Cisgender” create similar confusion and unnecessary division that prevents people from understanding each other.  Therefore, in some domains, knowing the good terms is so important that you don’t get your diploma if you don’t master them, such as in health or aeronautics. In some areas, using the right term is a matter of life and death.

What is the relationship with software development? The reason is that semantics are fundamental in the day-to-day work of knowledge workers and this is often the case with failed or poorly understood Scrum implementation. This goes from the very definition of a product owner to more fundamental things. But what motivated this post, besides my own observation of the problem (in many other contexts, as well), is the discovery that this phenomenon was much more widespread in the software industry than I thought and that it tended to annoy some (and that’s the least we can say).

In a recent blog post, Gregg Caines put it more gently, but very well:

When you want to get people to change the way they work, and you want them to understand the completely foreign concepts you’re bringing to them, it’s absolutely crucial that you name the thing in a way that also explains what it is not.

He continues with an example:

In Scrum, it’s also common to have a “sprint commitment” where the team “commits” to a body of work to accomplish in that time frame. The commitment is meant to be a rough estimate for the sake of planning purposes, and if a team doesn’t get that work done in that time, it tries to learn from the estimate and be more realistic in the next sprint. Developers are not supposed to be chastised for not meeting the sprint commitment — it’s just an extra piece of information to improve upon and to use for future planning. Obviously naming is hugely important here too, because in every other use of the word, a “commitment” is a pledge or a binding agreement, and this misnomer really influences the way people (mis)understand the concept of sprints. Let’s face it: if people see sprints as just more frequent deadlines (including those implementing them), the fault can’t be entirely theirs.

It is highly conceivable that Scrum defines new terms to impose a new way of thinking, as well (Agile Mindset). Ironically, this requirement is perhaps what contributes to the numerous failures of implementation of the framework, but also, and more importantly, to the proliferation of alternatives which infuriates its creator.

The lack of centralized and detailed information about Scrum can also contribute to the problem. The official scrum guide, with only a few dozen pages, is as highly subject to interpretation as your astrological sign of the day. The underlying psychological phenomenon for both is exactly the same:  it’s called the Barnum effect. It’s the tendency to interpret a general text to be specific to us. When it affects us, we filter the information and make it “match” our beliefs or knowledge, as I mentioned in the introduction. Sometimes it goes very far and I have already seen people develop theories about the functioning of the human brain based on sacred writings. This really makes me sad because the creator of Scrum probably agrees with me as they introduced transparency in the three pillars of Scrum along with inspection & adaptation:

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard, so observers share a common understanding of what is being seen.

OK, so far so good, but who benefits from the crime? Probably the agile consultants. It is possible for many of them to fill the electricity needs of an entire city simply talking in front of a wind farm. But how much does it cost? If I only rely on my experience to answer, I can attest that three generations of highly paid coaches are sometimes needed to make an organization understand agile fundamentals. Having been a “confluence archaeologist” several times, I can also attest that in some cases, it could never have been otherwise if the definition from my predecessors I read was the one submitted to the top management. They are not helped by the terms they need to promote.

That’s why I’m in favor of calling a spade a spade. Product Manager is the term everybody understands. It generally covers everything a “Product Owner” is supposed to do. I have the exact same opinion for the “Scrum Master” role (the “Servant Leader”), which creates further confusion, especially in different languages where the term servant is taken literally, and often leads to a “Scrum Janitor” or worse, a “Scrum Manager” in badly implemented Scrum. The guide mentions that it is simple to understand. I object. It also mentions that is it difficult to master. I agree. But one of the factors is definitely its inappropriate terms that create a breeding ground for misunderstanding. Therefore, a brave act would be to redefine the terms that would lead Scrum to the next level.