Pssst…You’re Allowed to Stop Using Jargon

Let Me Tell You a Little-Known Secret

I’ve been in countless conversations with teams that use words like Project, Product Owner, Epic, Story, Task, Agile…and, frankly, they had no idea what they’re talking about. People talk past each other. Misunderstanding grows.

Who is allowed to write a Story?
> Who approves the list of Epics?
> When will the Product Owner enter all the stories into Jira?

These are bizarre questions. When I hear them, I understand people are trying to figure out how they should coordinate. But the words are causing them to lose sight of their work. I get the sense that people think those words are laced with rules and norms — this is often due to fundamental misunderstanding of the words and their original meaning.

I often want to let them in on a secret: “Pssst…you are allowed to stop using jargon.”

I Didn’t Realize the Subject Was So Sensitive

As I consult with many teams, I often recommend they avoid such words and, instead, speak plainly about the work they’re doing.

So, I posted this simple idea at LinkedIn and it blew up!

It might be surprising to learn, given that I’m a professional Scrum and Kanban trainer, that I advise against the use of jargon. But in my line of work, I hear a lot of industry-specific acronyms and buzzwords that cause confusion and miscommunication.

If asked to make a list of the most misused, misunderstood, confusing terms, I’d surely include Agile, Agile Coach, Agile Release Train (ART), Agile Transformation, BDD, Ceremonies, Continuous Integration, Epic, Kanban, MVP, Scrum, Scrum Master, Spike, Sprint, User Story, and Velocity.

The temptation to use buzzwords is strong. Why?

• To signal expertise or insider knowledge.
• To reinforce in-group versus outsider dynamics.
• To capture attention (such as in marketing materials).
• They may seem like shortcuts while relaying complex concepts.
• The prevalent digital tools, unfortunately, reinforce their use. (Atlassian, I’m looking at you. Azure DevOps, you too!)

Give Your Teams (and Yourself) Permission to Stop Using Jargon

Working Agreeme7nts, Working Agreements, Working Agreements

As I get older, I increasingly feel that effective teamwork is always the result of strong working agreements.

How to use (or not use) jargon should be decided by a team and perhaps documented among a team’s explicit working agreements.

A Brief Story

In 2015, I consulted with a company that had a deaf employee in one of their teams. The team had agreed to try Scrum and they had been at it for a few months already. I was asked to observe and offer advice (e.g., “coach”).

In the first meeting I attended, I was absolutely gobsmacked to hear plain and simple English — no buzzwords!

And there was silence! A lot of silence. After someone spoke, a few seconds would pass before another person would speak. With some teams, I think people are uncomfortable with silence — so they speak excessively and fill every available second. Not this team. Quite the opposite. It felt a little like spending time with my dad — he’s generally a quiet man and speaks only when there is something important to say.

These two behaviours in the team were so odd, unlike any team I had met, they had to be deliberate. It was no accident.

The truth is as boring as it is obvious: the members in this team had explicitly agreed, for the benefit of their deaf teammate, to avoid jargon and to not interrupt or speak over each other.

Simple!

The deaf member could read lips very well, but only if he knew who the speaker was and if their language was uncomplicated by jargon.

I got to know them over the course of a few weeks and I learned that most of the team members found it easy to abide this very unusual agreement. I also learned that the agreement pre-dated their Scrum training.

Why is that important?

The Scrum framework is loaded with jargon. Sprint, Product Backlog, Daily Scrum, et cetera. None of these words occur in the wild — in fact, the authors of Scrum deliberately chose words that were unique so they could assign special meaning to them.

This team, as they attended a Scrum training course as a group, had a prior agreement to avoid the use of jargon. So, I found it interesting and awesome that they honoured their prior agreement even after studying Scrum with a trainer.

Scrum is just another set of agreements that a team may adopt — and while studying the design of Scrum (i.e., the description of the framework; The Scrum Guide™), it is important to abide the terminology carefully. But there is no rule that a team must adopt those words. Rather, Scrum encourages teams to establish working agreements that improve communication and are complementary to the framework.

This team, when they returned from their Scrum training course, took the time necessary to decipher Scrum’s jargon so they could keep to their prior agreement.

When Do I Use Jargon?

I teach Agile practices like TDD, Scrum, Kanban, User Story Writing, et cetera. I’m submersed in jargon daily. I find that I use jargon to advertise, to market my services. Or put another way, I use the same keywords my potential clients are using — even if, while in discussion with my clients:

• great effort is spent to demystify those same keywords,
• I help them talk in plain terms about their ways of working,
• and I encourage they establish working agreements to avoid the use of jargon.

Glossary of Common Terms

Over the years, I’ve written extensively about “Agile” practices. Below are links directly to sections of my website where I’ve attempted to clarify commonly misused/misunderstood jargon.

Have I missed one?

If there’s a buzzword out there that you think causes confusion, please send me a message and let me know. I may write on the topic.