Working in an agile way is now the norm for software development, IT and digital professionals (two thirds of companies describe their way of working as ‘agile’ or ‘leaning towards’ agile). And it’s how we work at Co-op Digital.
It’s a way of building products and services in gradual phases, instead of delivering it all at once, at the end. It means giving value to the people who will use the product as early as possible and letting them influence the direction of the product . It puts the user (in our case the customer, member or colleague) at the centre of the design and development process.
But agile comes with its own set of terminology and jargon. Search for ‘agile jargon’ and you’ll be met with a collection of dictionaries, glossaries and jargon-busters to help you understand the specialist vocabulary. ‘Sprint’, ‘kanban’, ‘scrum’, ‘MVP’, ‘retrospective’: there’s hundreds of terms that make up these aids.
What is jargon?
The Oxford Dictionary defines jargon as:
“Special words or expressions used by a profession or group that are difficult for others to understand.”
Sometimes jargon can be used as a shortcut to communicate a complex concept. It can be used to show that a person is a specialist in their field or connected to a certain community.
But, if we use jargon, we restrict the audience to those who understand the terms — it’s only understandable to those who know.
Why jargon’s a problem
As with many agile teams, Co-op Digital works with more traditional parts of the business. Recently, I’ve been working closely with Co-op Food. We couldn’t build a successful service without our Food colleagues’ knowledge and expertise. The least we can do in return is talk about these services in a way everyone understands.
This collaboration also gives us the opportunity to show the value that the agile way of working can add to a project and the rest of the business.
Agile often works best when it converts people — when it’s demonstrated an effective way of working to people who were initially sceptical. We should make the effort to make this transition as easy as possible for people.
But, by openly using agile jargon within a wider setting, we risk isolating the very people we want to help work in this way. If someone does not understand the vocabulary being used, it can be unnerving, alienating and mean they misinterpret an important part of what’s being said. Research shows that the less people understand, the less they trust the people telling them the information.
Using jargon can be inaccessible, ineffective and damaging.
What agile teams can do better
However we communicate, we should be inherently humble of what we assume. And good communication should not assume any specialist knowledge of the audience.
When we write for users of Co-op products and services we learn about the language that they use and make a considered effort to speak to them in a language we know they understand. We should do the same when we’re speaking to the wider team about our processes.
That means not using specialist terminology (or, at the very least, adding a plain English definition at the point any specialist terms are used) if we’re communicating:
- publicly about our work
- to people outside of our immediate team
- to people who are new to a team or organisation
By doing this we’re not only removing barriers to comprehension, but showing that we’re open, transparent and respectful of our audience’s time.
- Economic jargon promotes a deficit in understanding, The Guardian
- Why workplace jargon is a big problem, The Huffington Post
- Dumbing down, Sarah Richards