How Should Agile Teams Deal with Leaders Who Won’t Listen?

Today, Certified Scrum Trainer Scott Dunn shares his insights about the pain felt when leadership doesn’t listen—and what you can do today to combat this problem. Scott is a popular trainer here at Mountain Goat Software, known for his empathy, sincerity, and practical enthusiasm for making Scrum stick. Want to get certified online? Click here to see Scott’s upcoming class dates.

“We’re going agile!”

To teams struggling with the chaos of waterfall or other non-agile ways of working, this can be a welcome battle cry: the start of a new and exciting journey toward higher productivity, quality, and job satisfaction.

But for some, it can be the beginning of a demoralizing process that leaves the organization worse than it was before.

Have you ever experienced the following pain?

Your company has ‘gone agile.’ There’s been some training, and you and your team are settling into the cadence of working in sprints. It’s not perfect yet; the deadline is still tight and there’s probably more workload than is reasonable. But you’d grown accustomed to this pace in the past, and the end of the sprint is in sight. In fact, you might just do it.

That is until someone from senior management turns up with a list of new priorities that absolutely have to be completed. The previous ‘absolutely must-have priorities’ that were added just after the sprint began seem to have been forgotten.

Someone knows that agile rules are being broken and feels brave enough to speak up, only to be told:

“Find a way to make it happen. If you can’t be a team player…”

The subtext is clear: Do as we say, or you can be replaced.

Why hasn’t the move to agile worked?

Are management just being jerks?

I don’t think so. Don’t get me wrong—bad bosses do exist—but from my experience, the above situation happens because of two key factors:

  1. Leadership underestimate the actual changes required to be agile, AND
  2. Leadership either don’t receive feedback, or don’t listen to it

1. Leadership Underestimates the Change that Is Needed to Be Agile

When I come in to coach at companies struggling to transition, I commonly find a lack of understanding about just how much needs to change in the organization.

Leaders often accept that team members will have to switch roles, or need new resources, but they might believe that changes will be contained within the team. For agile to really work, the process must also be understood and respected by stakeholders and customers.

It’s like following a recipe but missing a key ingredient. You might get something that looks a bit like the meal you wanted to prepare…but it tastes awful.

Companies can cause a definitely awful experience when they follow some of the rules—sending people to train as Scrum Masters and Product Owners—but skip key principles.

And I hate to say this, but agile IS partly to blame.


Because it makes bad work habits visible.

Teams have always faced last-minute requests, increasing scope, changing priorities, impossible deadlines. But these problems were buried in the chaos. It wasn’t easy to see why things weren’t working (just that they weren’t) so stakeholders assumed that teams just couldn’t finish on time.

Agile brings into focus the reasons why a team can’t finish on time.

For an organization that truly wants to embrace an agile process, this is a good thing: it shows what needs to be fixed. Agile can survive leaders who don’t initially understand what wider changes need to be made.

When things really go wrong, it’s because:

2. Leadership Either Doesn’t Receive or Doesn’t Listen to Feedback

It’s not always easy for team members to speak up when they see management breaking agile rules. Scrum Masters may not have the authority or approval to take feedback up to the next level—and even if they do, the issue could linger at the management level, never reaching a director or the C-suite.

Unfortunately, sometimes the long-anticipated meeting with management yields nothing more than the response outlined in that previous example: merely an insult or a threat.

Why is it difficult to get leaders to listen to feedback?

One problem is that, for some leaders, we’re trying to get them to change the very actions or attitudes that previously helped them get great results. Often a leader has succeeded due to quick action on an idea that might seem rash and impulsive to some, but decisive and can-do to others. Companies often reward (and promote) people with these strong, ambitious “we can do this if we all just pitch in” attitudes.

And strong personalities may be quick to assume that the problem lies with the person bringing the complaint. Their knee-jerk assumption is that it’s just an excuse for the team to avoid work.

Obviously this is a generalization and I’m certainly not saying all leaders are like this. I’m saying that if you have leaders who have underestimated the changes needed to go agile, and refuse to listen, it can definitely present challenges.

The Cost of No Feedback Is More than Wasted Time and Money

If leaders refuse to accept feedback and adapt their behavior, agile will never work. We’d be shocked by the financial cost in wasted time, resources, and potential productivity gains as a result of this.

But I believe the higher cost of this is killing hope. Hope–according to research by Gallup into strength-based leadership–is one of the top four needs of employees who are in ‘follower roles.’

When an organization makes the decision to go agile, teams have hope that things will change, that productivity will improve, and they will achieve personal satisfaction from delivering quality products at a sustainable pace.

But if this doesn’t happen, the team will feel even worse than before. Hope has been taken away and all the initiative has done is reinforce the fear that nothing will ever change.

When hope leaves an organization, it’s usually followed by your best people.

Companies that don’t listen to the needs of the team can suddenly discover one day that they have a workforce that no longer goes the distance—everyone’s simply punching the clock, having learned how to survive in this broken system.

Leaders who don’t listen to others will eventually be surrounded by people who have nothing to say. – Andy Stanley

So What’s the Solution?

When it comes to giving and receiving feedback, one of the most important things to have is a feeling of psychological safety. In fact, research by Google showed that this was one of the top requirements of an effective team.

This means that team members need to feel safe to take risks and to be vulnerable in front of each other. Teams with high psychological safety operate with confidence. They need to know that they can raise ideas without being embarrassed or punished for doing so.

When this happens between teams and leadership, you have more productive dialogue and can build truly great things by accessing the wisdom of the crowd.

Easier Said than Done?

I’ll admit this is not an easy change to make in any organization, but that does not mean all is lost.

While I can’t promise you overnight success, here are three things that you can do today to initiate long-term change.

Pull Back Before You Really Lean In

I’ve rarely (if ever) seen it work to simply beat the rule-breaker with the rule book.

Repeating “that’s not how Scrum/agile works” tends to reinforce management’s perception that the team is just trying to get out of doing extra work.

The alternative is being willing to bend.

A Scrum Master I knew had a VP approach him with a special project that would need a brand new team. He wanted to immediately pull members from other teams and put them together to work on the initiative.

This was classic decisive behavior: something needed to be done and the VP searched for resources to make it happen.

The Scrum Master explained it would be disruptive, but the VP pressed on and finally, the Scrum Master replied:

“Okay. Let me check with the other Scrum Masters and see what this would look like and how we could make it happen; then we can talk about it.”

Seeing progress, the VP left happy.

When the meeting came around, all the Scrum Masters gathered and collectively explained why it was breaking the rules, and why they couldn’t do it the particular way he wanted.

But…they also discussed how it could happen within a Scrum framework. Seeing this willingness to help him achieve his objective, the VP was also more willing to listen to alternatives.

I can’t guarantee this approach would work every single time, but there are a number of elements you can try in a situation like this to increase the likelihood of a positive outcome:

Resist the urge to simply tell someone the request is wrong/outside of the rules. This is more likely to increase tension.

Try to find common ground. While you might disagree about the how, you may be able to agree that you both want to achieve the same things: better quality, higher output, etc.

Buy time to present a better case. The Scrum Master didn’t just have safety in numbers at his follow-up meeting with the VP, he also had time to think about how to present a stronger case.

Plant the Seeds of Change and Water Them…Consistently

Another example was a Scrum Master who was relentless when it came to presenting concerns to management. But he did it in such a calm and unobtrusive way it didn’t damage relations: it actually helped create real culture change.

Working with multiple teams, he would take concerns into decision-making meetings and raise issues without pushing too hard. His attitude was positive even if his requests were denied.

In addition to this, he kept all of his teams informed so they didn’t lose hope. They could see that someone was working on their behalf, and that at least the message was being presented to the next level up.

Over time change did happen.

Managers started to consider some of the persistent problems, and each small change built traction towards bigger changes until the company really had embraced what it meant to be agile.

Earn the Right to Request a Change

This one can be a little harder to hear but sometimes I’ll encourage a team to show how great they are before they complain. What would happen if you pulled out the stops for two to three sprints and then asked for something to change?

This isn’t a magic bullet, but it does show that you’re not just a team who says no. You’re not trying to get out of doing work. You are in a better position to negotiate if you can point to all the deadlines you’ve hit, rather than being seen as a team that breaks promises.

Sometimes you just have to prime the pump before you get water from the well.

How Have You Helped Leaders Listen?

I’d love to hear from you. Do you have any feedback about horror stories? What’s been effective for you when it’s time to improve the relationship between teams and senior management?

I know there’s definitely psychological safety here at Mountain Goat Software, so I’d love to hear all of your ideas.

Share your thoughts in the comments and let’s use the wisdom of the crowd to help solve this problem.

Get an Excerpt from A Leader's Guide to Agile eBook

Get an Excerpt from A Leader's Guide to Agile eBook

Help your teams succeed with this exclusive sneak peek at 3 of the top 10 things leaders need to know.

Scott Dunn

About the Author

Scott Dunn has more than 20 years of experience in management, project management (PMP), engagement management, and software development (MCSD). He’s worked in a variety of areas and industries from social media to mortgage banking, healthcare, defense, e-commerce, plus state and local government sectors.

He has helped coach and train at dozens of companies transitioning to an agile approach using Scrum. Clients have included EMC/Dell Technologies, Yahoo!, LaserFiche, Kaiser Permanente, Rovi/Tivo, eBay, and GE Healthcare.  
Scott is passionate about strengths-based teams and solutions-based approaches to people and organizational issues. He is an enthusiastic and encouraging trainer. 

Scrum Certifications include: CSM, CST, CSD, CSPO, CEC, Educator-CAL, CAL-1, CAL, A-CSM, A-CSD, CSP-SM, CSP-PO, CSP-D, Path to CSP Educator, CSD Educator, Scrum Foundations Educator.