Not everyone on the team supports the decision to do scrum. How do I resolve that conflict?

Not everyone on the team supports the decision to do scrum. How do I resolve that conflict?

That is a great question because it really is so contextually dependent. It really depends on that specific person and what their resistance to scrum is all about.

  • Why do they feel that way?
  • What are the experiences that have led to that decision or opinion?
  • How did that decision to oppose Scrum come about?

All these things matter. They may very well have a valid reason for opposing scrum and until you surface those reasons, you’re simply going to fail to change their mind or resolve the conflict.

Imposing Scrum on a team

If someone has been told to do scrum, that isn’t a great place to start. Imposing a new style of working on a team without first describing and articulating the benefits of what you are proposing is going to lead to all kinds of resistance.

Imposing scrum or any other agile framework almost always creates problems.

What we want is for a team to agree that scrum or an agile framework is a great opportunity for them to explore and for them to want to adopt the framework willingly and enthusiastically.

If scrum is being imposed on a team and they resist, fair play, I completely agree with them.

If you told me I must play football, I simply won’t. I don’t like football, I’ve never played a game in my life, and if you forced me to, I would simply stand there and allow everyone else to play the game around me. I just wouldn’t participate.

You will face something very similar if you impose scrum or a new style of working on a team.

They will simply allow things to happen around them, but they won’t actively contribute, nor will they participate in any meaningful way.

Understand why the team are resisting

So, if you do find yourself as a scrum master or agile coach in a situation where a team is actively resisting or opposing the adoption of scrum, you need to start by understanding why.

Open the conversation by asking whether scrum is a good answer to the problems or challenges the team currently face. Ask if there are any other great answers that people are aware of and explore what their thinking, line of reasoning, and challenges are.

Explore what they consider to be the problem and how much knowledge they have of scrum or the agile framework that you are considering adopting.

Maybe, somewhere in that conversation you identify a way of working that the team actively want to adopt which aligns well with what the organisation wants to achieve. Great. You have a starting point that allows the team to move forward.

Understand why the team want to work in this new way and what perceived benefits they imagine will arise from this new style of working. Identify and track metrics which will allow the team to measure whether the new style of working is indeed successful and whether the team are achieving their goals.

It may not be scrum that is adopted but it will be something that everyone is onboard with and that is a great start. That outcome is better than any other style of working where people are disengaged and actively resisting processes, systems, and engagement.

Over time you can work with the team to adopt the practices that make sense and discard those that slow the team down or create problems within the organisation.

It is exactly what you would do in a formal adoption of scrum. You would work with the team to identify practices that serve the team and identify those practices which are unhelpful, so technically you are facilitating an adoption of scrum, you are just doing it on the team’s terms not your own.

Previous bad experiences with scrum

So, what do you do when a team have formally adopted scrum in the past, unsuccessfully, and the team are resisting based on their previous experience?

You first step is to understand what they were doing, why they were doing it, and how they were doing it. In many cases you will discover that the team were doing something, but it wasn’t scrum. It was just called scrum or that is how they identified it.

Great. You have uncovered practices, behaviours and methodologies that don’t serve the team and you can agree that those won’t be implemented or adopted in any way. You can agree that what they did in the past didn’t serve them and set about identifying what will work for them.

It is about finding a way to help the team move forward and sometimes that involves compromise. Sometimes, you identify a starting point and get cracking.

Over time, you can introduce new practices, ideas, and concepts which the team can adopt based on the data and evidence that you show them. If there is no data, you can run an experiment and the team can work through that data in a sprint retrospective to identify whether the new practices and experiments have helped them improve or not.

If they have facilitated improvement and the team agree with the evidence, great, you won’t have any resistance to introducing that new practice, idea, or concept. If the evidence reveals that the experiment was unsuccessful, you can explore why it was unsuccessful and whether it is worth pursuing over a few more sprints or whether it is better to abandon right away.

Again, it is evidence-based and empirical.

You may even find that you are guiding the team away from scrum because the evidence and data is informing more effective ways of working and the team are co-creating that new style of working with you, based on evidence and experience.

Great, we aren’t evangelists for scrum, we simply use the framework as a great starting point and evolve with each iteration from there. The framework is purposefully lightweight and flexible for that reason because we are supposed to continuously improve and evolve.

If everything stayed the same, with rigid rules and constraints, we wouldn’t be improving as a team, nor would we be moving closer to business agility. We may as well go back to waterfall-style project management if that were the case.

Being a great scrum master and agile coach is about doubling down on the things which help the team and minimising the things that don’t serve or help the team.

Teaching and Scrum Education

Sometimes, you need to go right back to basics.

I often start the conversation by asking the team what they think scrum is. I ask them to describe what scrum looks like and test their understanding of what scrum is intended to do.

Once the team have had their say and we have identified the depth and breadth of scrum knowledge within the team environment, we can start planning training and workshops that will help the team learn and grow.

A scrum master and agile coach blend training, coaching and mentoring to assist teams understand scrum, its benefits, and identify opportunities for growth and continuous improvement.

You do need to teach scrum, help people understand how it came about and how it has traditionally served organisations.

  • What are the origins of scrum and what problems was it designed to solve?
  • Where has it successfully been implemented and why?
  • How could a scrum adoption serve the team you are working with?
  • What does great scrum look like?
  • What can the team expect from a scrum adoption?

In many cases, you will also need to teach the product owner how to be more effective at their job and walk them through useful tools, models, and frameworks they can adopt to better communicate their product vision and what the product goals are.

You may need to extend that teaching into the realm of customers, product stakeholders and people within the organisation that work closely with the scrum team. You may need to host workshops, facilitate conversations, and actively teach agile principles and values.

This can be incredibly rewarding and fun. I love my role as a Certified Scrum Trainer and I love teaching workshops and certified Scrum training courses.

You see people grasp the concepts and through the demonstrations and exercises, they actively witness the power of a scrum team in full flight. You see how this knowledge and experience transforms people and their attitude toward scrum.

Embrace the teaching opportunities available to you and blend coaching and facilitation skills to ensure that the team are always engaged, interactive and inspired.

So, those would be my 3 tips for you.

  • Understand why the team are resisting scrum
  • Examine their past experiences and probe for insights
  • Challenge their knowledge of scrum and create teaching opportunities

If you like the idea of becoming an Agile coach and would value mentored, coach-driven skills development in your journey to mastery, visit Growing Agile Coaches with John McFadyen.

If you like the idea of becoming a scrum master, visit our Certified Scrum Master course page.

If you are already a scrum master and want to upskill, and both validate and certify your professional skills, visit our Advanced Certified Scrum Master and Certified Scrum Professional Scrum Master course pages.

For more insights into how to become a better scrum master, visit John’s YouTube channel and blog.

#agile #agilecoach #agileprojectmanagement #agileproductdevelopment #scrum #scrummaster #certifiedscrummaster #advancedcertifiedscrummaster #csm #a-csm #johnmcfadyen

author avatar
John McFadyen Managing Partner
John McFadyen is an Executive and Enterprise Agile Coach with proven experience working on some of the UK and Europe’s largest, most complex Agile Transformations. As a Certified Scrum Trainer, John brings a wealth of experience as an Agile coach, Agile practitioner and software developer into each of the four core courses he provides. The war stories, the insights into successful Agile transformations and everything he has learned from coaching high-performance Agile teams combine to provide course delegates with a unique, compelling training experience that transforms as much as it empowers.

Like this post? Share with friends & colleagues using the share buttons below.


Related Blog Posts

Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen