How to convince a skeptical team to give Scrum (or other methods) a chance

The first time I worked as a Scrum Master with a team, I did so under less than perfect circumstances. The organization didn’t have any experience in agile methods. It actively pushed back against the new approach. Some of the team members were skeptical of the experiment. It wasn’t easy in the beginning. But we did reach our goal in the end and I learned a lot in the process.

Today I want to share what I learned in convincing a skeptical team to give Scrum a chance. My goal is to help other agile coaches, scrum masters, product owners, or project leaders tasked with implementing a new (agile) approach. 

I am going to share the eight best practices that worked for me. My hope is that they may help you get going as well.


The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 


Eight best practices to convince skeptical team members

To start with the obvious, humans don’t like change. They especially don’t like change for the sake of change. It’s natural for team members to be skeptical of a new approach. Even more so, if they work in a corporation that tries to sell them on the new and en vogue, silver-bullet approach to product development every few years.

Thus, it can be difficult to get buy-in from the team members. The most effective way to create an open mind to a new approach like Scrum is showing what is in it for them. Making the daily work of the team easier and building a relationship on eye level are the key. The following eight best practices are aimed at doing exactly that. They will help you be successful: 

  • Be part of the team
  • Explain why (often)
  • Be pragmatic in applying Scrum
  • Make the team members feel heard
  • Optimize their workflow
  • Don’t treat engineers as implementation robots
  • Build technical knowledge
  • The joker: witnessing iterative product development

Let’s start with one of the most obvious points that many still get wrong.

Be part of the team

I see this far too often: your task of setting up the (Scrum) team often comes from upper management. This is great for confidence. After all, leadership is trusting YOU with implementing this new approach. It can also lead to arrogance. 

Don’t act like you are something better! In Scrum the Product Owner and Scrum Master are part of the team. Act accordingly. There are a few specific things you can easily do.

In the stand-up also share what you are currently doing, instead of simply having the developers give their updates. Involve the team members in important decisions. Give the team the autonomy to come up with their own solutions to problems. Involve team members in strategic discussions with other stakeholders. Always share relevant information. 

In short, create a team culture where everyone feels that they can speak to each other – especially with you – on eye level. 

Explain why (often)

There are (hopefully good) reasons why leadership wants to try out a new approach. Explain those. You can’t do this enough. Describe what the organization is currently struggling with and how this new method is hoping to help. 

Additionally, explain why the framework works the way it does. What is the point of the Sprint Review? Why does it make sense to have a refinement session? Why do sprints exist? These are the types of questions that you need to answer. Your explanations will lead to better understanding and in turn to more acceptance.

The important thing is not to try and sell the new approach as a silver bullet that will solve every problem. The people have heard that plenty of times before. Rather, plainly state the situation, what you are trying to achieve, and what the underlying principles are.

These principles are always worth coming back to. Don’t compromise on them. 

Be pragmatic in applying Scrum

You can compromise on the method – I suspect many will disagree with this statement. But I deeply believe it. 

The Scrum Guide is clear on how Scrum works. It is a very rigid implementation of agile principles. This is a good thing for many teams. Especially less mature teams greatly benefit from clear rules and regular checkpoints. Mature teams don’t need as much hand holding.

Thus, it makes sense to be pragmatic in implementing Scrum – or any other framework for that matter. Assess your situation, see what works for you, and adapt the method to your circumstances. 

Some things that have worked for me in the past: 

  • Having a pre-refinement meeting
  • Mixing elements of Scrum with a Kanban approach
  • Conducting a team internal review and a public demo
  • Adding a weekly design review meeting

There are infinite possibilities. Whatever pragmatic modification to the method works for the team should be an option, as long as you still adhere to the underlying principles.

Optimize the team workflow

It is not only true for the method but also for the process: you should modify it so that it works best for the team. For some reason, many don’t seem to realize that this is an option.

Changing a process by removing a senseless step – plenty of those in the automotive industry for sure – will earn major plus points with team members. Just make sure you are not breaking any laws in the process of doing so. 😉

Optimizing the workflow for the team leads to increased efficiency and a happier team. A win all around. 

Make the team members feel heard

Speaking of a happier team…actually listening to the problems of the team members and doing something about them makes people feel heard. This, in turn, builds trust and a positive atmosphere that will lead to better outcomes. 

Talk to the team members in one to one conversations and actively listen for their problems. Chances are that the current processes and tools are not optimal. Chances are the team members are frustrated in one way or another. Chances are also there are some easy fixes. 

By doing this, you are showing that you want to actually help in making the team members’ daily work as easy as possible. You are showing that you care about the team as individual humans. 

Don’t treat engineers as implementation robots

Engineers are also humans, believe it or not. They can do more than just implement features defined by someone else. I wholeheartedly agree with Marty Cagan, who says that “just using your engineers to code, you’re only getting about half their value.”

Engineers are the main source of innovation. They know what is possible with current technology. All you need to do is provide them with business context and make sure to connect them with customer or user pain points. This unlocks their full potential.

In practice, engineers should be involved in discussions with design, marketing, or other stakeholders. They should regularly interact with users, e.g. through weekly interviews. Involve them in usability testing. 

Finally – and this should normally be a given but it often isn’t – let the engineers come up with solutions themselves. Don’t tell them how to solve problems. They know best.

Build technical knowledge

You don’t need to be an expert. But it does make sense to make an effort to at least build up a base level of technical knowledge. Don’t be afraid to ask about technical concepts. People enjoy sharing what they know. (Also the beginner’s questions often expose some flaw that the experts never thought about).

A basic level of tech knowledge will make work more efficient. The developers won’t have to explain simple technical concepts to you. You can focus the discussion on what is important. This communication (almost) on one level will have many positive effects, including but not limited to building trust between developers and yourself.

The joker in convincing a team to give Scrum a try: witnessing iterative development

There is one thing I haven’t mentioned so far – and I will end on this – that is the absolute killer in convincing skeptical team members. It’s not so much a best practice but more an experience, witnessing iterative development of a product. 

Without a doubt, this is what is most convincing to skeptical team members. Building a small improvement, getting it out in front of users, and watching them interact is so inspiring and motivational. Without fail, once the team members witness this, they are hooked. 

So, if there is one single thing to do it is this. Aim for deploying as often as possible and reviewing the impact together with the team. This is convincing. Everything else is gravy.

Coverphoto by benzoix on Freepik