4 Signs Your Agile Coach is a Fake

Today’s business world is saturated with Agile Coaches, Scrum Masters, and certifications. Everyone is “going Agile” (if they haven’t already). Companies across the globe are engaging Coaches to guide their organizations and teams.

Why are some gaining immense value with Agile, and others frustrated and failing? Not to say it’s all contingent upon the Coach – company culture, structure, and leadership have a hand in it too. But without a great coach, what happens to nearly every team?

They lose.

Have you ever encountered an “Agile Coach” who can talk the Agile Talk, but in practice, they’re clueless?

In this post, we’ll share red flags that show whether your “Coach” is actually a Fake! You’ll learn how to spot a dodgy coach, and how to know when you’ve hit the jackpot and found a great one.

Red Flag #1: Your Agile Coach is obsessed with Buzz Words

“They won’t realize I have no idea what I’m doing if I use lots of Agile words.”

While we expect people to be honest on their resumes and at interviews, that doesn’t always happen. I don’t want a coach with an impressive resume and credentials galore if they can’t deliver results.

There seems to be an army of “coaches” these days who’ve never actually been on a team – of any kind – let alone an Agile team. They try to mask it by “sounding smart” and being vague about their experience. They are obsessed with Agile buzz words, and constantly use Scrummy language.

A great coach doesn’t need to show off their vocabulary. They know it’s just “the way we do our work.”

Take Apple TV+’s Ted Lasso. Ted successfully coaches a professional soccer team, and he doesn’t even know the rules of the game.

How, you ask? Keep reading to find out.

Red Flag #2: Your Agile Coach is extremely prescriptive

“This is how it’s done. Any other way is simply wrong!”

A Fake Coach sees their beliefs about Agile and Scrum as absolute truth. They are not to be questioned or altered in any way. They know the rules (or at least think they do), and treat everything as set in stone.

A good coach understands that the Agile Manifesto and Scrum Guide provide guidelines. Yes, there are prescribed roles, events, and artifacts. But how we incorporate these practices is up to the team.

One size does not fit all. No two Agile or Scrum adoptions look the same! People have a significant effect on how everything plays out.

Ted Lasso’s at it again with a radically different approach to managing the AFC Richmond team. They don’t have to function the same way as the team with the most wins.

Ted helps the team discover what’s best for them.

Wait a minute…I thought the coach had the final say?

Let’s dig into that a bit more.

Red Flag #3: Your Agile Coach always has an opinion…and they are always right

What are some other words for “coach?”

Trainer, instructor, teacher, mentor, educator.

I don’t see manager, executive, supervisor, director, or administrator on that list.

So why does your coach impose their opinions and ideas on everyone else?

A Faker masquerading as a Coach always has an opinion…and they believe they are right. They tell people what to do and how to do it. They focus on specific outcomes, putting their own goals over those of the customer and team.

What does a good coach do differently?

They ask questions. A lot of them!

To be great, a coach doesn’t need to know everything about how to do the work. I’ve coached four software development teams, and my technical skills stop at very basic SQL and HTML. Don’t even ask me the difference between C# and Python.

In all these situations, my teammates – the developers – knew what they were doing, and I trusted them to do it. The value I added wasn’t technical. It was focused on people.

The same can be said of Ted Lasso. He’s a soccer coach who doesn’t know the definition of “offside.” But the team, assistant coaches, and staff are experts. Ted asks questions, takes input from everyone, and keeps his ego in check.

We all have egos, there’s no denying it. But on a team, what’s more important – “me” or “we?”

Red Flag #4: Your Agile Coach doesn’t understand teamwork

Consider the synonyms for “coach” mentioned earlier – trainer, instructor, teacher, mentor, educator. Think about the mentors, teachers, and leaders who have most impacted your life or career. What made them positive or negative influences on you or your team?

In your worst experiences, did you feel psychologically safe? Was everyone on the team treated with respect? Was it ok to try and fail? Did you, your teammates, and the coach all have clear expectations? Did people work together and support each other?

Probably not.

A great coach makes people feel safe, and knows that failure is simply an opportunity to learn. They make sure all voices are heard. They understand the complexities of team development and dynamics.

Coaches help people work together, learn together, and improve together. They acknowledge the value each person brings. They are highly invested in other people’s success.

Like Coach Lasso says, “…success is not about the wins and losses. It’s about helping [the team] be the best versions of themselves on and off the field.”

So, is your Agile Coach the Real Deal, or are they a Fake?

I bet you already know the answer to that question.

If the red flags described in this post sound familiar, don’t panic! The Internet is full of misinformation, and “copying without knowledge” happens every day. Your coach may not even know they are too involved, too prescriptive, or that they sound like an Agile dictionary. If they do know and are still doing it…you might want to find a new coach.

Anyone who wants to learn can and will! And if they don’t, now you have the tools to spot your very own Ted Lasso in the crowd of mediocre “coaches.”

If you’re interested in learning more about Agile, coaching, or Scrum Mastery, check out our coaching services and upcoming courses here! 

Apple TV+ Ted Lasso

Why Scrum Case Studies Don’t Work

You may be asking, “what do you mean Scrum or Agile case studies don’t work?” Afterall, isn’t the point of a case study to provide information about the successful Scrum or Agile transformation? Yes, case studies do just that. They provide the information about a particular company and its journey. But please remember that any Agile approach, Scrum in particular, means change. Structurally changing and behaviorally changing.

In Collaborative Leadership Team’s experience, there are 2 reactions to Scrum or Agile case studies that simply don’t work. Or that do more harm to your organization’s agility than good.

1.  Cognitive Dissonance: When asked for “real” examples of organizations adopting Scrum or Agile frameworks we provide real company case studies in our classes and in our coaching. These examples contain factual information about decisions made, structural changes made and behavioral changes made. Yet countless students and clients then immediately reply with “Well that won’t work for our company because (fill in the various reasons)”. Dr. Harvey Robbins gave us a simple explanation. It’s cognitive dissonance. Even when presented with facts, the people in question will start to rationalize or hold true to existing beliefs that prevent them from making those changes. It’s not a case of “Scrum doesn’t work” or “Agile doesn’t work”. They work. If used as intended. If an organization does not want to change, they could choose not to. But there’s no value in calling something Scrum or Agile if there is no change behind it.

2. Copying without Knowledge: It’s great if case studies inspire your organization to change or to do something differently. But there is no quick fix, no magic pill or any shortcut. Too many organizations think they can simply copy another organization’s journey. Dr. Edwards Deming called this “copying without knowledge”. He noted that American management thinks they can just copy Japan but they do not know what they are copying! The same is true with Scrum and Agile. How many people try to copy Spotify? Never mind that their business has nothing to do with an online music streaming business, they just copy buzz words that Spotify doesn’t even use and say they are doing the “Spotify Agile method”. Even though no such thing exists. The reality is that every company has to take their own journey. They have to talk to each other, make decisions for their own business, make structural changes along with behavioral changes to achieve those goals and objectives.

What can you do instead? Create your own “case study.” Really make the structural and behavioral changes required and discuss what was learned from doing that. It doesn’t have to mean changing the entire company at once. It can be as simple as starting with one product or one initiative but really making the necessary changes. Then determine if goals and objectives were met for the product release or initiative. Were they not met? What did we learn? What could be improved?

If you are interested in learning for yourself and curious about how to get your own journey started, we’re here to help. Whether it’s joining our free user group, accessing free podcasts and blogs or attending one of our live, online workshops, check out our course schedule here.