Resolve conflicts in Agile Teams for Scrum Masters and Agile Coaches

Last updated on: Published by: Asad Safari 4

Almost 9 years ago, when I started my first scrum mastery role, I encountered one of my tough challenges, conflict resolution. Two members of the development team(Ali and Vahid) separately told me we can not work together anymore. 

  • “Why do you think you can no longer work with him? ” I asked them. 
  • Ali: “He doesn’t respect me… he is a brilliant jerk… I could not be able to work with him anymore”.
  • “Ali is not a good team member, he is so lazy, and he does not care about the team… I don’t like to work with him… ” Vahid told me.

I held a shared meeting with both of them to help them to resolve the conflict. Everything went as severely as possible. This meeting was like the first presidential debate in 2020 between Joe Biden and Donald Trump. Attacking, Interrupting, Not listening. I was like Chris Wallace at this meeting, without any impact. Ali left the team at the end of the week. 

This bad event was a trigger for me to start improving my conflict resolution skill. Especially this kind of workplace and personal conflicts. If your team members have a conflict in the decision-making process, you can use easily facilitation techniques, but personal conflicts are so difficult. A conflict is a situation when the interests, needs, goals, or values of involved parties interfere with one another. 

In these 9 years and while coaching almost 20 different teams, I have experimented with many practices to resolve conflicts, but I want to suggest an effective one that worked for me in different situations.

Ladder of Inference

Ladder of inference, developed by a former Harvard professor Chris Argyris. Experts using the Ladder of Inference refer to “travel” on the ladder as an important way to obtain valuable insight into how a belief or action may have developed. The practice of traveling on the ladder also provides a rich opportunity to articulate the core of those inferences with other individuals and groups, particularly ones that lend themselves to vastly different conclusions and the escalation of the conflict.

It’s a really easy framework to learn, and adopt it as your favourite conflict management tool. Let me describe it with my own story. In our story, Vahid believed that “Ali is not a good team member, he is so lazy” (Beliefs) So, In meetings, he did not show respect to Vahid (Actions). On the opposite side, Vahid developed a belief about Ali for himself too and reacted to him.

Learning to “travel back down” the ladder to revisit, articulate, and communicate the original data each group holds in a certain light is key to increasing meaningful communication between members of a group or team while simultaneously managing conflicts more effectively. 

The key point is that, helps them to revisit or be aware of the root of their current beliefs. 

Let’s travel back down the ladder in action:

  1. We are in a planning meeting, Vahid is trying to explain a concept to the team to help them to break it down a complex task into small tasks, there are 6 team members there…. (Observation)
  2. Ali is starting to check his phone (Selected Data by Vahid)
  3. His attention is on his phone (Meaning)
  4. He is not paying attention to me (assumption)
  5. He did not care about the team (Conclusion)
  6. He is a bad team member (Belief)
  7. Ignore the Vahid at the during of this meeting (Action)

When we developed a belief about somebody, next time, we will just select data about him based on our current beliefs. Beliefs act as a filter for us, we did not see things that we do not intend to see. 

Our beliefs affect the data we select next time. So, After this planning meeting, Vahid just will see some actions of Ali that prove his belief. It is not interesting? More evidence will cause stronger beliefs and stronger conflict. It’s a loop.

Another big mistake is that You as a facilitator, try to just pay attention to actions and try to manipulate them. Lets, say Vahid, you should show respect to him, but Vahid created a strong belief about Ali that he is not a good team member. And the same thing happened to Ali too.

What we should do? Travel back down the ladder. 

As a facilitator, you should help them to travel back down the ladder. What happened that you think he is not a good team member? “He did not care about the team…”. Can you tell us why do you think he does not care about the team?

You can start this session by explaining the ladder of inference framework, you can use your own stories too, it creates good empathy. For example, I always use my story with my wife and how we developed a wrong belief about each other. She thought I did not care for her anymore, and I thought She is just a murmur… And how we used this ladder to understand what created this kind of belief. For example, Checking the phone at home when we are eating lunch, caused she developed this belief…

This image is a great example to show your team member.

People develop beliefs in just seconds by some limited and selected data. And these beliefs influence their actions and view of the world in the future. We should help them to be aware of the root of these beliefs, observe new data and facts, and maybe develop new beliefs.

Don’t hesitate to share your experience here with me 🙂

Best Regards

Asad Safari

Maybe you like:

Create a real agile team with Fogg behavior model

Last updated on: Published by: Asad Safari 0

As an agile coach, I try to help and empower companies to find their own way and move forward in their agile transformation. But there are companies that just hire me to hold a 2–3 days agile/scrum workshops for them.

I want to tell the story of one of these workshops for a company that we call it “Manko”(Not a real name). All team members, Team leads and managers participated in the workshop. There was a different type of people with different ideas and beliefs about agile:

1-Agile is a great thing and we need to follow it 2- Agile is a new fad and this trainer try to sell his gold hammer to us 3- No idea about agile and curious to learn new thing.

In my courses, I always try to reach the following goals and help the teams to stick to the change after my workshop.

1- Awareness(Why we need to change?)

2- Desire(Everyone or part of them has the desire to take part in and support the change.)

3- Knowledge (What is the Agile and different frameworks, and how they work?)

At the end of my workshops, I try to measure my result with these questions(Do they have the motivation and enough knowledge to start the change? ). 

For “Manko” case, at the end of the workshop, everybody was happy and they told me, “We will start to practice from tomorrow and …”. It was so exciting for me. 

After a while, I asked them “What is going on there?”, And in response, “Yeah, we are so busy now but trying to write user stories on Jira but developers didn’t update it … Some days we have daily standups, hmmm, not regular and…”. 

It was so surprising for me, Why such motivated guys could not succeed in their change plan? 

I thought we just need motivated guys to be able to change, and motivation can drive the change. But it was a wrong hypothesis.

The Fogg Behavior Model shows that three elements must converge at the same moment for a behavior to occur: Motivation, Ability, and a Trigger. When a behavior does not occur, at least one of those three elements is missing.

Based on this model, We have Motivated guys but low Ability and no Prompt or Trigger

Maybe you think that Why they don’t have enough ability? Why your course didn’t make them be able to work agile. 

We need to understand the difference between Knowledge and Ability. In a 2–3 days training course, You can just create knowledge for them and not the ability. Even simulations or any kind of games cannot create Ability. 

Ability comes from daily and real work. Once the knowledge(theory) is in place, then the individual needs to be supported during the actual performance (practice). They need to do it and make mistakes and learn and repeat and practice. 

For example, you are trying to write user stories together with all team members. But you don’t know how to write or breakdown stories for your real project in the banking industry. It will create frustration for team members and as a result, they will put it away 🙂 

Cognitively Demanding (Mental Effort) — People probably already have a lot to think about, so any new behavior that they are trying to take shouldn’t increase their cognitive burden too much.

So based on the Fogg model, We need to make teams be able to change their behavior. 

Hire Scrum Master/Agile Coach For fostering ability:

  • Coaching or role-modeling in the real work environment
  • Access to right tools
  • Give Feedback
  • Co-Working with a team, for example, breaking down stories together

Trigger or Prompt

Ability and Motivation are not enough to change behavior. We need to a trigger too. There are three types of the trigger, each aimed at a slightly different audience.


The spark is a trigger that comes with added motivation. It’s perfect for those who have the ability but lack the motivation. 

Our training course sometimes works as Spark trigger. When it comes to training, a spark should help a learner see the Epic Meaning in the behavior you’re asking of them. They want to know why it’s important, and it’s up to you to make them care.


A trigger that is applied when there is high motivation but low ability. It seeks to simplify the task. As an illustration, suppose that you’re trying to eat healthier but you’re not very organized. You can sign up for a newsletter that is delivered every Sunday morning to your inbox with easy-to-make, delicious recipes for healthy meals. This will prompt you to sit down with the newsletter and plan your meals for the upcoming week, right there and then.

I think in our case Scrum Master or Agile Coach can be a great trigger for the team. She can work with them daily, Send them small pieces of training, Show them how to do a task(Like breakdown story),….

For example, I was an Agile Coach in a big enterprise, We tried to use OKR in company level. We held training courses for teams about OKR. Some of them started to write their Objective and Key results in the company’s confluence. So I started to check their pages, and comment for them. 

  • “Hey, Vahid, How do you want to measure this key result “Improve the speed delivery?, Do think we have any number to measure? like Deployment count per week?” 

Or I shared good OKRs as good internal examples to other teams in our social messaging groups. 

Or One-on-One mentoring with managers to check their OKRs. Giving feedback to them …


They are ready to change. They have the motivation, they have the ability, all they need is the starting gun to fire and they’ll get going. This is just a prompt that serves as a reminder. It can be something as simple as a post-it note.

Scrum masters and Agile coaches can create ceremonies or some reminders for teams to act as a signal. For example, weekly meetings for checking and tracking OKRs. 


I think, for sticking on agility, companies need to hire or develop empowered Scrum masters or Agile coaches or any kind of agile practitioner. 

Agile coaches/Scrum master need to understand, three elements must converge at the same moment for a behavior to occur: Motivation, Ability, and a Trigger. 

If your team is not motivated about agility, let them know about the meaning and philosophy of Agile, you can ask help from external agile coaches/trainers. 

If your team doesn’t have the ability and it makes them frustrated, act as a facilitator and mentor, Work with them, Create a product backlog together. Create a safe space to learn by doing. (Company and senior leader should support you in this stage). 

Sometimes you need to act a simple reminder. Ask questions “Hey, When do you want to do grooming meeting in this sprint?”

Maybe you like:

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He has worked as an Agile coach for more than 7 years with several enterprises and startups. He has more than 14 years experience in the IT industry as a Software Developer, Tester, and finally an agile practitioner. You can follow Asad on Twitter and LinkedIn.