4 Things Decision-Makers Get Wrong When Hiring An Agile Coach For Their Organization
People often mistake agile coaches for mechanics that can “fix” businesses.
When a company is struggling with efficiency, or transparency between departments, or even just internal communication at large, a decision-maker within the organization will reach out to someone like me to help them streamline efficiencies. For context, I am one of approximately one hundred Scrum Alliance Certified Enterprise Coaches (CECs) in the world, and I specialize in working with enterprises often managing hundreds, if not thousands of employees.
The problem, however, is that I am not a mechanic. If you have a broken car, you bring it to a mechanic and they fix it before handing it back to you. However, when a company realizes they have a broken structure or process for their team, they think they can do the same thing: bring their broken process to an agile coach who will “fix” it and then hand it back.
And that’s just not how it works.
Working with an agile coach is about creating a partnership in which someone like me brings their expertise to the group to create a frictionless and self-evolving team environment. And that partnership is leagues away from the one you form with a consultant—or a mechanic.
Instead, here’s how the process is intended to go:
1) We make a plan together.
Where a consultant solves a problem for the client, an agile coach solves it with them.
My entire value is to create a solution where the client has three-quarters of the pieces and I have one. My job is to then bring new problem-solving and relationship-building techniques to the table so that it’s not just the immediate list of problems that get solved, but all future problems as well (otherwise I would be on retainer for a very, very long time).
In the agile community, we call this the coaching relationship agreement, and it’s a fundamental piece of what we do.
In this agreement, we’re careful to be very explicit about what the customer’s outcomes are. For example, it may be, “I want to deliver this software product on time, I want my people to be happier, and I want to have a clearer understanding of the customer.” Then we look at the activities we can do to help them achieve those goals. We also take the metrics into consideration: where are we today and where do we want to be six months from now?
This gives us a list of activities, a coaching transformation log, and measurable goals we can achieve together. Then, we check in periodically to see if we’re actually moving toward those goals. If not, we change things.
2) It’s not just about delivering a product—it’s about developing a culture.
A huge issue I see again and again in coaching is what I like to call “culture blindness.”
Someone will say, “Make sure my team releases on time. And you should do it by making sure that they’re estimating correctly, the requirements are correct, et cetera.” But what’s actually happening is the Chief Architect and the Chief Product Owner hate each other.
In short: there’s usually a surface problem—and then the actual issue lying under it.
The typical focus is on solving the surface problem as quickly as possible without addressing the underlying issue. But that deeper conflict tends to be harder to solve—things like safety, trust, shared understanding, alignment.
In an effort to get teams to look beneath the surface, a very simple exercise I do is bringing together the executive group and saying, “So, what is the goal here?” Each person will write on a sticky note, silently, and we’ll just look up and see if the goals match. If they don’t, then we’ll say, “Oh, okay, that’s because different people in the organization want different things.” Point being, it doesn’t really matter what we’re doing at the technical level if the VPs aren’t agreeing on what it is they actually want.
That means one of them will always be losing—and that’s a huge blind spot.
3) A team’s underlying emotional issues can have major impacts.
In order to be frictionless internally, a team needs to be aligned. We should be glowing when we’re doing the right thing. But that also means addressing personal blocks in addition to what’s slowing down the company.
For example, one personal block I had for a long time was that I thought my father was better than me, and, therefore, I shouldn’t make more money than he did. I’d get close to making as much money as him, and then I would self-sabotage. This is a common issue for many people—we learn dysfunctional behaviors from our family and then bring them to the workplace.
The challenge is these things tend to be deeply buried, so we may not even know they’re there.
But finding ways to address personal blocks can lead to seamless work and a sense of congruence. And what I mean by that is a sense that what you’re doing is what you love. It may be so frictionless to do this work that it’s almost soothing.
A beautiful example of congruence is Tom Brady, the Patriots player (who just won another Super Bowl). His dad has said that what sets Tom apart from his peers is he loves everything about football—even the parts other players hate. He loves watching tape, doing the workouts, following the diet. Tom has said before he watches tape for three or four hours a day because it’s soothing for him.
This type of complete and total congruence is the goal of agile coaching. Then there’s no resistance with any person, customer, or project.
That’s purity. That’s oneness. And it comes from getting through your own emotional blockage.
4) Numbers are important—but not in the way you think.
A lot of clients will come to agile coaching because they think their quality of X (whether it’s a product, a service, a process, etc.) is terrible.
But when I ask them how terrible, they’re never able to answer. In my 10 years of coaching, I’ve never had a company answer that question.
What it actually comes down to is the team has “bad memories.” They launched a product and were miserable the entire time, or felt unappreciated at the end of a project. But in order to figure out what was making everyone so unhappy, we still need those numbers. And it can take months to sort through all the data simply to get a snapshot of how things are working.
So, I usually start people off with a set metrics dashboard that includes finding answers to the following questions:
- How much? As in, how many “widgets” are you producing each week?
- How fast? How long does it take to create that item from the second the conversation starts to when it’s finished?
- How good? What’s the quality?
- How predictable? If you tell a customer to expect an item within a certain number of days, how frequently do you meet that deadline?
- How happy? Is your team happy and is your culture healthy?
As an example of these questions in action, I worked at a large Fortune 500 company that literally spent three months doing annual planning across a 3000 person organization. And all the director level people and engineers were involved in it, but they absolutely hated it. They would produce 200-page PowerPoints from their meeting. So, I asked the planning group, “What is the relationship between the plan and those PowerPoints?” And the answer was, “There isn’t one.”
I’ve learned, in moments like these, you have to really question why teams are doing what they’re doing—and if certain activities don’t add enough value or move the needle, stop. And as a result, people become less irritated, have more free time, and ultimately feel like the work they are doing has a purpose. And that’s the goal.