Avoid Getting Good At Agile

Agile Jargon Is Like A Foreign Language

I know the agile universe has been around for a long time. You may have even been using agile concepts since XP or Scrum in the mid-90s, I get it. But if you were to line up every single person in your whole country that works at all the organizations, large or small, and ask them how well they understood what it means to be agile, what do you think you’d find?

For far too many people, agile is still like a foreign language.

Overall, the world is still not really all that agile.

Software development and IT functions in organizations are typically 60 to 90% agile but every other department in a company is more like 10 to 20% agile or less. (Generalizing statistics from the State of Agile Report)

Unless it’s a tech startup, the average Small to Midsize business is likely even less fluent in agile.

So what?

Well, for an Agile Coach like me, it’s great to know that if interest continues to increase as it has, there are still plenty of opportunities for my skills to be needed. (They’ve just been trickier to find recently. If you’re a coach, do check out my friend Marina Alex ’s Sway System to learn how to market to SMBs…)

The Jargon is Off-Putting

If you believe my rough math above, there are many people who are still learning about agile. Maybe you remember your experience learning agile or have taught others to whom it was very foreign. When it’s new, the agile jargon can be overwhelming. There are new words for so many things, often things that people have done before by a different name or are familiar with, but now… now, they are joining an agile team and being taught “new ways of working” and “new ways of thinking”.

There are new ideas, but in order to absorb it all in a context they understand, sometimes people start by thinking “agile is just like stuff I’ve done before, it’s just a new set of rules.” It seems innocuous, but in my opinion, is dangerous and the likely cause of many failed transformations.

This idea sets up a mindset shift that is subtle and happens so slowly that people don’t even notice. The mindset sets in while they are initially still learning agile, so it is even harder to shake later. Coaches do this too without realizing it sometimes. Companies that don’t have a lot of experience with agile will make this mistake too (perhaps because they only hire people with fresh new certifications and very little experience).

From the very beginning, if an individual or team is concentrating too much on learning how to be agile and treating it like new words and new rules without enough context around why it matters, they are unwittingly being setup to fail.

The mindset setting them up to fail is that the goal is to be good at agile.

Learn how to conduct a good standup. Don’t assign work to people, let them pull the work. Do estimating. Don’t do estimating. Learn how to slice user stories. Get good at the agile “ceremonies”. Conduct refinement, prioritize the backlog… the list is endless. These are the things people are taught first, so it’s no wonder they think it’s just new jargon and new rules.

In learning how to be agile, sometimes people either forget or are never taught that the goal is still to be good at delivering business value to customers and end users. And it is not emphasized enough how important it is that agile is a new way of thinking, not just fresh paint on old ways of working.

Treat agile like it’s common sense

So, how do you escape the trap of just trying to get good at agile?

One of my tricks is for an agile coach or Scrum Master to repeat at the start of any agile event why they are there and what they’re trying to accomplish. Do that until everyone is sick of it and mouths the words themselves. “We are here at standup not to give a status, but to find ways to collaborate, uncover problems sooner, and see how we can get more things done.”

It’s common sense. But a reminder as to why they’re doing things keeps it real and removes any specialness or artificialness that might be reinforced, for example, by calling an agile event a “ceremony”! A standup or daily scrum is not a sacred event, it’s a quick sync for the team to be effective everyday.

The same is true not just of the other agile events (no matter what framework or method you’re using) but also for the agile mindset shifts that we teach people and teams to embrace when they’re learning agile.

Instead of teaching the mechanics of how to slice user stories, make sure to discuss why we slice user stories. Iterative Thinking is part of the agile mindset and it’s important that teams work in small, iterative pieces in order to maximize the chances of learning something sooner. Getting feedback on what works and what doesn’t work sooner helps build better products faster!

A user story is not just another name for a requirements document; it’s a small experiment with a desired outcome that will prove or disprove we’re on the right track to deliver the right value to the customer. Teams that haven’t learned this will write very large user stories with tons of details, itemizing every aspect of how a piece of functionality should work. They are often acting like that one story will implement a feature completely in one fell swoop, the same way we wrote large design documents in 1997. That team may still have a lot to learn about thinking iteratively. Or worse, they may believe that they are getting good at agile and therefore are on the right track.

Watch out for these signs that you’re slipping into the “get good at agile” mindset.

Teach the Agile Mindset

As an Agile Coach, I look for opportunities to make fun of agile to help the team come back to focusing on the business and why they’re doing the work they do. I say things like “who cares? what…? are the agile police going to arrest me?” purposefully so that we don’t treat agile like it’s a new set of rules to be followed perfectly. That said, there are reasons why we do things the way we do, but it’s more important to understand why so we can deliberately decide if it’s ok to skip an event or do something differently.

My focus is always on helping teams understand the Agile Mindset. And yes, I capitalize it only because I’ve gone to great lengths to describe what I mean by it. So much so, that a year of my life was poured into writing a book on the topic: The Practical Agilist Guidebook.

In this book, I describe exactly how I coach teams to learn the Agile Mindset. There are 24 topics and I describe the behaviors a team needs, and the concepts they should understand to fully embrace the why behind the modern ways of working. The topics fall into four obvious categories of Team Culture, Agile Process Basics, Product Management, and Value Delivery.

If you’re interested, please reach out. I’m often running specials on Amazon and in early 2025 have been running book giveaway contests, shipping dozens of books for free to people who are genuinely interested in learning and using the information. At any given moment, I may even have a few books on hand that I could ship you an autographed copy at a discount!

It is my passion to share this information with the world in hopes that more teams and more companies find ways to continuously improve themselves in their agile learning journey.

Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the complexity of the agile universe into easy to understand and simple common sense.

Curious? Ask for a free consultation.

The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an Agile Coach teaching you the behaviors behind the Agile Mindset, why the topics are important, and what you can start doing about it. It also includes Scrum Master and leadership tips, AI prompts to help you explore and dig deeper, and tons of recommended books, videos, and articles.

Paperback and Kindle Available on Amazon.