Conflict
There doesn’t need to be any conflict between the roles in SCRUM. One nice thing about SCRUM is that it clearly defines people’s roles and responsibilities. Of course, we live in the real world, trying to help real people with their own problems.
A healthy team will be able to talk about conflicting needs and address those directly, or come to an accommodation. Where there are conflicting needs for different roles, the organisation should make adjustments so that these needs are no longer in conflict, but rather all align to the same goal. Highlight to those that can affect these changes the conflict these opposing needs are causing and suggest a possible adjustment they could make to help them align.
When thinking about attempting to address conflict, keep in mind that most behaviors are the result of a Positive Intent. Once you understand what that intent is, the solution may become obvious. At the very least, acknowledging that positive intent and stating your own, can help reduce friction as you all search for a solution together.
If conflict is not about behavior, but about a personality clash, you probably have a low chance of being able to resolve it. Instead you may have to settle for mitigating it's impact using tools like Team Norms, Team Vision, Definition of Ready and Definition of Done. We work in a professional environment, so ultimately if the parties involved can't find a resolution then we just need to make sure we act and behave as professionals.
As a SCRUM Master don't feel that you need to resolve every conflict. Coach the Team and PO in conflict resolution themselves. Coach them in emotional intelligence. Or if you feel you don't have the skills to do this, then maybe external training in these areas may be worthwhile for the company, rather than lose one or more of it's employees.
Here's a little table about who owns what in SCRUM (its not comprehensive, so will be updated from time to time):
Who owns What?
Product Backlog
Owned by PO, but anyone can add to Product Backlog
Content / Scope of Work Items
Responsibility of PO
Priority of Work Items
Owned by PO
Sprint Backlog
Owned by Dev Team
Quality of Work Done
Responsibility of Dev Team
Work Item Order within Sprint Backlog
Owned by Dev Team
State of Readiness of Work Items
Responsibility of PO, with assistance from Dev Team
Getting Work Items to Done
Responsibility of Dev Team
Completing All Sprint Commitments
Responsibility of Dev Team
Definition of Ready
Owned by Dev Team
(More detail on the SCRUM roles can be found here: Introduction to SCRUM)
Product Owner
There doesn’t need to be any conflict between the PO and the SM. One nice thing about SCRUM is that it clearly defines people’s roles and responsibilities. (Yes, I'm repeating myself.. sorry!)
As a SCRUM Master basically has no responsibility (apart from facilitating meetings and removing impediments where necessary), there is almost no grounds for any conflict.
Saying that I have seen this conflict quite often.
From what I’ve seen where this conflict occurs, it is usually the SM being outraged that the PO has stepped over their area of responsibility and firmly planted their feet in the space that’s reserved for the team.
So, I think the first thing to do is recognise that conflict exists as early as possible. This will require a level of awareness and emotional intelligence from the SCRUM Master. If it’s identified too late, then the job of untangling it becomes a lot more difficult.
Conflict with a PO is sometimes the result of external pressures on that PO, so to resolve this you may want to sit down and discuss the problem with the PO. Use the feedback techniques or difficult conversation training you may have been given. Explain the behaviors you’ve observed the PO doing and how they made you feel, or how they made others feel. Find the reason why the PO behaved like this. Specific examples work best, so make a note of them when you notice them.
I’ve seen other conflict happen as a result of the character of the PO. They thought they were higher that the Dev Team in terms of business structure hierarchy. If they are considered senior to the team, then work with the company so that they understand that dev team members and PO need to have the same level of seniority / authority… i.e. The PO is just a SCRUM team member the same as a SM, the same as the Dev Team. Once you’ve fixed the broken company structure (if it was broken), then you can get to work adjusting the behavior of the PO.
SCRUM, defines who owns what. There’s enough information in there that should help you resolve most conflicts.
User Story scope is regularly changing when in sprint
Possible Adjustment
Get the team to identify when scope has changed (stand-up may be ok for this if not before). Get the team to re-estimate the story (don’t let this take over the entire stand-up). Tell the PO that we can either postpone the amended story to a following sprint or remove other sprint items. Let them know how many points of work need to be removed and remove items until the Team is happy with the new commitment.
If the PO refuses (I’ve seen this behavior) and insists everything stay in the sprint, then rather than argue, simply explain that some work is now unlikely to now get completed and by not deciding which stories to remove, the PO is giving up the right to decide which ones that may be
PO regularly adds items to the sprint after it has started
Possible Adjustment
Make it clear that the Dev Team own the sprint backlog and a PO is not permitted to change it once the sprint has started. You will also have to coach the team, often using retros after they failed to deliver sprints, to stand up for themselves and not accept work items into sprint without consensus from the team. Often a PO will try and use a particular team member to get things into a sprint that has already started. Explain to the team that they can not bring things into sprint without the agreement of the whole team. This then gives that team member the backup of the whole team if they need to say no to the PO. Also coach the PO in that if they overload the sprint the team will achieve less, and the PO will lose control of the relative priority of items
PO is constantly trying to manage the team in terms of the work items they are working on and what they pick up next.
Possible Adjustment
Coach the PO around the roles and responsibilities of the PO and the team. Try and find out what they feel the need to try and manage the team. Often, it’s about knowing when work items will be done, or if a work item will be completed by end of sprint. These are both legitimate concerns for a PO, so show understanding. Try and produce information for the PO that gives them the information they need. Try and coach the PO not to make promises to customers about delivery dates. One of the most effective ways to reduce this PO need is to help the team deliver on their sprint commitments regularly, so the PO can trust that the work they took on will be done by end of sprint.
If all of this is still not working, then consider moving from a coaching stance to a protection stance for the Team. Plant yourself directly between the Team and the PO. SCRUM has several tools for this:
As the owner of the SCRUM process you can decide how the SCRUM ceremonies are run. If the PO is disruptive or unhelpful in the daily stand-up (the most common place for attempted micro-management of a team), then simply exclude the PO from this ceremony. Explain that it’s a ceremony for the team to coordinate the day’s work ahead and not a reporting or management platform
Work items are never sufficiently groomed, meaning the team often must rework or must spend time trying to figure out what’s needed to complete the work item.
Possible Adjustment
There is something we can use in SCRUM called the Definition of Ready. It is basically a tool that can be used to prevent poorly defined work items becoming a problem for a team. By stating what is required as a basic minimum for a story to be accepted into sprint this can be used to filter out all work that will disrupt the flow of a team. Get the team together and agree a basic format and evolve this definition over time from feedback from the team’s retrospectives.
Coach the Team to understand that they are empowered to not take in a story to Sprint if they feel it is not understood enough or doesn’t meet the definition of ready. If the PO really isn’t doing their job (its their responsibility to make sure the Product Backlog is sufficiently groomed), then the team may not have any work ready to accept into sprint. Which means they now have lots of time for personal development, or maybe do some refinement sessions to get stories ready for next sprint!... This quickly brings the PO back into focus.
Coach the Team and the PO to understand that the sprint backlog is owned by the Dev team and that no-one else has the right to add or remove items from there without the consent of the team. In addition, no-one has the right to modify items once they have been accepted into the sprint backlog without the consent of the team.
Hopefully these tools will be enough to adjust the behavior of the PO (and to some extent the Team too)
Dev Team
There is often a lot of presure placed on the development team. They are, after all, the people writing the software. They'll have coding puzzles to solve; business requirements to understand; other people's code to understand; their own code to understand. They're the ones responsible for trying to write software that's easy to understand, easy to maintain, is performant and fulfills all of the buisiness requirements in the most robust and user friendly way possible. They may need to do this to a deadline, or a series of milestones, or just have it done yesterday.
I say all of this as when encountering conflict within a development team, in order to understand it's cause, you may need to consider the pressures that are applied to it. Often conflict comes from applied pressure.
It's not the scrum master's responsibility to resolve team conflict. However, by helping the team to learn how to recognise and resolve conflict, you will end up with a much more robust team that is able to address friction early on - before it becomes unmanagable. This in turn can result in a happier team and better quality of life for everyone involved.
Team members are consistently late for meetings
Possible Adjustment
Firstly consider not taking any action. How much of a problem is it really? The answer may be its not really a problem, to it's a huge waste of eveyone's time.
Listen to the team. If they are not bothered by someone being late, make sure you have a good reason to intervene. And no, just because it annoys you is not a good enough reason.
Coach the team that it's ok to hold people to account for being late. Try by making anyone late to the daily scrum buy donuts for the team.
RESPECT is one of the five SCRUM values. Use this as a teaching opportunity for team members to respect each other's time as being important. That includes the PO's and the SM's time too.
Listen to the reasons why someone is consistently late. You may be able to solve this by adjusting the meeting time (starting it 5 minutes later for example).
Team members are consistently complaining about other teams
Possible Adjustment
This is pretty common, esspecially (but not only) when the teams are working on the same code base.
Firstly consider not taking any action.
If you decide action needs to be taken, make sure you don't get in the middle of the conflict. Your role here is to help the people involved resolve the conflict themselves.
Get the person raising concerns to give specific concrete examples of where the friction exists, don't accept generalisations as, although they are an indication of more advanced conflict, they are very difficult to act on. When you hear phrasing like "They always mess that up", or "they never put proper comments onm their commits". you know the conflict has already escalated to a serious level.
Does the complaint about another team directly affect this team? If not, then teach the team about the Zorro circle. Their inner circle is one where they have influence; the second is where they are impacted, but have little or no influence; the outyer circle is things of interest that do not impact them. Identify in which circle the behaviours causing this conflict exist.
When appropriate bring the concerned parties together to talk about what's happening and what the reasons for the behaviours are.
If in the outer circle, then empathise with the team member but there is probably nothing else for you to do in this case except listen to the frustrations.
Scrum Master
As a SCRUM Master basically has no responsibility (apart from facilitating meetings and removing impediments where necessary), there is almost no grounds for any conflict.
If you find yourself in conflict with someone else then the first thing to do is take a look at your own behaviours. As well as having almost no responsibility, you will also have almost no authority.
Scrum Master is telling the dev team what to do
Possible Adjustment
Stop doing this. This is as much a problem if the Scrum Master does this as it is when the Product Owner does this. You have no authority to tell anyone what to do beyond running the four basic SCRUM meetings (daily standup, sprint planning, sprint review and sprint retrospective). Beyond this very limited scope you don't have any authority to dish out work, prioritise work, demand status updates, or get the team to try changing things up to improve.
Instead, use a servant leader approach of supporting, encouraging and defending the team so that they have space to learn, grow and experiment in a safe envioronment. Make sure blame is not part of the team or company culture and a safe space is created where failure is accepted as a consequence of constantly trying to improve.
Scrum Master is forcing the team to try changing things
Possible Adjustment
Stop doing this. You have no authority to tell anyone what to do beyond running the four basic SCRUM meetings (daily standup, sprint planning, sprint review and sprint retrospective). Beyond this very limited scope you don't have any authority to dish out work, prioritise work, demand status updates, or get the team to try changing things up to improve.
Instead, use a servant leader approach of supporting, encouraging and defecnding the team so that they have space to learn, grow and experiment in a safe envioronment. Make sure blame is not part of the team or company culture and a safe space is created where failure is accepted as a consequence of constantly trying to improve.
Team is just not listening to the Scrum Master
Possible Adjustment
Reflect on your behaviours. Have you been overstepping your boundaries? Do you feel you are more involved in the work instead of being focused on how people are working. If you are, then why are you focused on the work instead of the people? Are there external pressures on you?
Try to determine if there other external pressures on the team that conflict with a healthy running of SCRUM. Do they have objectives that are distorting their behaviour? If you identify any then try and tackle them at source to get them either removed or adjusted to be more aligned with healthy SCRUM practices.
Another hard question to ask yourself is: have you lost the respect of the team, and hence your effectiveness as a leader? Can you see a way to regain this, or should you go your separate ways for the benefit of everyone?
Manager
There is no manager role in SCRUM, as a consequence their role is not clearly defined - which means there is a lot more potential for conflict. When dealing with what feels like conflict involving a manager you firstly need to understand what their roles and responsibilities are. Look at these and see if there is overlap with the roles and responsibilities of the three scrum roles. If there is an overlap consider if this is a cause of the problems being surfaced.
The roles and responsibilities in SCRUM are immutable. They cannot be changed. If you don't observe the roles and responsibilities defined in SCRUM, then you are not doing SCRUM. If you wish to continue to use SCRUM, this means that you will have to have the responsibilities of the manager adjusted so it doesn't conflict with the three SCRUM roles.
Below are some typical areas of conflict with managers in SCRUM.
Manager is giving work to team members that is not in sprint
Possible Adjustment
The product owner, as the sole owner of team capacity, must be able to prioritise all work for the team. Giving work to team members outside of this process produces an unhealth conflicty for that individual.
Coach the manager around the conflict this causes. How does that team member now prioritise work given to them by their manager against work that is sitting in their sprint backlog? Is the manager aware of the impact of not completing the current sprint items?
Coach all involved to ensure these pieces of work are refined and planned as backlog items into sprints. They should be prioritised by the product owner in partnership with the manager.
If they are short-notice, then that is the manager's problem, not the team's problem. Coach the team not to accept this problem as their own.
The manager is setting individuals personal targets that are odds with good team behaviours
Possible Adjustment
Highlight to the manager the personal targets that are causing the problems and demonstrate to them how these are being counter-productive. You've probably become aware of this through certain behaviours you've noticed, so try and make a note of these specific examples to give to the manager.
The manager is trying to manage the team in terms of the work items they are working on and what they pick up next
Possible Adjustment
Coach the manager around the roles and responsibilities of the roles in SCRUM. Try and find out what they feel the need to try and manage the team at this level. Often, it’s about knowing when work items will be done, or if a work item will be completed by end of sprint. These are both legitimate concerns for a manager, so show understanding. Try and produce information for the manager that gives them the information they need. Try and coach the manager not to make promises to customers about delivery dates. One of the most effective ways to reduce this manager need is to help the team deliver on their sprint commitments regularly, so the manager can trust that the work they took on will be done by end of sprint.
If all of this is still not working, then consider moving from a coaching stance to a protection stance for the Team. Plant yourself directly between the Team and the manager. SCRUM has several tools for this:
As the owner of the SCRUM process you can decide how the SCRUM ceremonies are run. If the manager is disruptive or unhelpful in the daily stand-up (the most common place for attempted micro-management of a team), then simply exclude the manager from this ceremony. Explain that it’s a ceremony for the team to coordinate the day’s work ahead and not a reporting or management platform.
If this is not working and you feel a conflict between yourself and the manager start to escalate then raise this with the manager's superior.