Chapter 3: Scrum Team Management and Conflict Resolution
Although Scrum certainly isn’t used in every Agile Project, the Scrum team framework is almost always present. A Scrum team allows the project to contain only three primary roles, which ensures that there is no unintentional hierarchical structure. However, even with only three primary functions, there will be conflict, the attempt at a hierarchical structure, and challenges within the team in terms of cooperation.
By understanding the roles and learning how to help resolve conflict, you can engage every member of the team. When you’re using a well-established framework such as Agile, you’re going to have conflict, and people who don’t quite fit the mold or don’t want to adhere to the principles and values. It happens. But while you’re working on a project, you need to get buy-in and get everyone on board with their position or role.
The Product Owner is the executive stakeholder. Sometimes they are called ‘the Champion’ while other times they’re referred to as the project manager, project owner, process owner, captain, or many other names. Essentially, they have the final word, and if you’re reading this with the intent of leading a project, it is likely that you’re either the Product Owner or the Scrum Master (more on that in a moment).
What does the Product Owner do? They’re the only established person “in charge” in a hierarchical manner. The original definition through the Scrum guidebook is:
“… is responsible for maximizing the value of the product resulting from the work of the Development Team.”
However, the guidebook also states that the Scrum Team will largely help determine how much involvement the Product Owner has. Every project will call for different levels of involvement, engagement, and coaching. It is important to note that the Product Owner is mostly responsible for the outcome of the project. The Product Owner is the only person that is responsible for managing the Backlog. It is possible, and even reasonable that the Development Team will create the Backlog, but again, the Product Owner is responsible for it.
SCRUM claims that there’s a necessary Product Owner Certification, but many businesses rely on the information publicly available about Scrum and Agile to develop an internal Product Owner. Additionally, because Agile is equivalent to “open-source” in terms of information availability, it is possible to access most of the information from the original Agile Leaders on this role without going through a formal training structure.
The Product Owner’s full scope of responsibilities can include:
● Creating the Backlog of “to-do” items
● Reviewing deliverables before arranging for product delivery
● Address or request changes
● Have the deepest understanding of the end user’s needs
When you’re looking at the wide variety of situations and responsibilities, everything comes back to one sentiment: the Product Owner is responsible for helping the team to create the most valuable product possible. During that process, they should help better the team and lead them through all challenges the team faced while working on the project.
For many people, the Product Owner is the person that’s seen as the manager. If someone from outside of the Agile Team were to approach someone with a request or concern, it’s likely that they would approach the Product Owner. However, the Product Owner doesn’t have any real hierarchical power over the Development Team or the Scrum Master. In fact, if there is any construct of power within the team, it is based purely on respect and can be lost quickly. Recall that Agile teams work because they are self-organized and mostly self-leading.
New Product Owners will often make the mistake of working as though this is a standard project. They act as a manager rather than a facilitator or a guide. However, the Product Owners aren’t the only ones who need to adapt their management mentality.
One of the key differences between Agile Teams and nearly all other teams is that the perceived manager or leader is not the person upholding accountability. The Scrum Master, an elected member of the Development Team who takes on a “player-coach” role, is the one keeping people accountable.
In the line of ensuring that a hierarchical structure is not in place, the Scrum Master, who will lead meetings and hold people responsible, is also a member of the Development Team. They must be a trusted manager who has worked with successful teams in the past and who is comfortable measuring progress under Agile Definitions. A Scrum Master doesn’t have to be an experienced Agile Manager, although they should be familiar with the Agile Workflow and positions.
A Scrum Master will take on the following duties:
● Update the Scrum/Kanban board daily
● Follow up on task levels and completions.
● Conduct analyses to determine efficiency and productivity
● Calls together the daily standup meetings
● Determines how to reduce friction within the workflow
● Commands accountability from both the Development Team and the Product Owner.
Although you would think it would fall to the Product Owner, it is usually the Scrum Master’s job to ensure that everyone is completing their tasks, getting the help they need, and working with the team’s agreed-upon processes. They are also the primary bridge for communication between the Product Owner and the Development Team.
For example, if a member of the Development Team does not thoroughly understand the expectations of the Product Owner for a particular function, it would fall to the Scrum Master to gain clarification. Initially, this seems like a chain of command. That very hierarchical structure that Agile claims don’t exist within its many methodologies, including Scrum. However, the use of the Scrum Master as a bridge for communication is not hierarchical. The Development Team can and occasionally will approach the Product Owner with questions and concerns. The use of the Scrum Master, however, provides a higher level of communication skills. Developers and coders often fall into using jargon and abbreviations that anyone outside of coding or developing wouldn’t understand. The Scrum Master takes that jargon and those commonly-used abbreviations among Development Teams and translates them into a common language that the Product Owner, who is usually a businessperson, can easily understand.
Becoming a Scrum Master doesn’t come from an assignment to the position. The Product Owner is not responsible for choosing the Scrum Master. The Development Team will choose their Scrum Master and provide an offer. However, the Product Owner can give their input. For example, if the Development Team chooses the most senior member of their team as the Scrum Master, the Product Owner might call to attention that they are simply enlisting the person with the most experience, not necessarily the person with the best communication skills. If you were approached to be a Scrum Master and you accepted the offer, then you should be very proud that your team thinks so highly of you and that the Product Owner likely has a high degree of respect for you as well.
The Development Team can have a number of people and most Agile Development Teams average between two and five team members, not including the Scrum Master or the Product Owner. These team members make up the greater majority of the Agile Team, and often their only focus is on software development. That means that even if these team members are part of your long-term IT department, their focus during software development should be exclusive to the Agile Project.
These team members stand apart from other developers or coders who may be able because they are specialists in accepting assignments, working collaboratively, and essentially getting the job done. The Development Team is often formed by the Product Owner and collaboration with the team member’s immediate managers if they are concurrent employees. Being approached to be part of an Agile Development Team can be a pretty special point in your career because you’re being acknowledged for your ability to work independently and work well within a team. Additionally, Development Team members are often recognized for their creative thinking abilities. That is often how Development Teams will choose the Scrum Master. They’ll look for the person who is most capable of communicating clearly and working to solve problems and resolve conflict creatively.
Team members will often work closely with each other, and they’ll review each other’s code and look at different ways to make all of their work easier and faster. There is no one set task list that applies to all Development Teams the way that the Product Owner, in Scrum Master, had a generalized responsibilities list. The Development Team will do whatever they need to in order to progress with the project. Of course, progress is defined as functioning software.
Finally, it’s important to note for Scrum Masters and Product Owners that not every member of the Development Team needs to have a history of working on an Agile Team. Often Agile projects will include a handful of people that have never worked with Agile Development before. In regard to that, the Development Team will often take charge of the greater majority of the project, but they will still require direction. Even those experienced in working on Agile Projects will need support and guidance.
There’s not a single or project or a team in existence that hasn’t experienced some type of complaint. However, Agile Complaints tend to be repetitive. From project to project and from team to team, most Agile Projects lead to the same or similar complaints. The most common Agile complaints include:
● “The organizational culture doesn’t fit Agile Values.”
o The purpose of Agile values and the Manifesto is that they exist because companies frequently, if not always, don’t have a culture that fits with Agile values.
● “There’s a resistance to change within the organization.”
o Development Teams should only worry about the development, and let the Product Owner handle the struggle with change resistance within the organization.
● “We’re not skilled or experienced in Agile.”
o Agile is a mentality, a series of values and principles that guide developers and the Product Owner. Work with the values and principles in mind, and that’s the best anyone can do.
● “The Product Owner/Scrum Master isn’t available enough.”
o These core people need to attend daily meetings and periodical meetings but must also make themselves available at other times. This is a problem that requires immediate correction.
The responses listed under these common complaints are what generally apply; however, your team may have unique situations that require a different response. Additionally, Agile Teams can include complaints beyond these issues. Interpersonal problems happen on Agile Teams as well.
The most important element of addressing complaints on an Agile Team is to provide a response or a resolution that promotes trust and relationship building.
Anonymous Complaints on an Agile Team
Most companies have an open-door policy that allows employees to file anonymous complaints to managers, human resources, or key contact people. Anonymous complaints on an Agile Team breed animosity and can ultimately lead the team to failure.
It is frustrating for many people involved to hear that there’s a complaint, and that person is not having the courage or the trust with their team to address it directly. If you are the Scrum Master or Product Owner and someone approaches you with an anonymous complaint you might issue these three options for resolution:
1. Arrange for a small meeting with the Scrum Master and two person’s involvement in the complaint.
2. Arrange for a group meeting.
3. Opt not to voice the complaint.
Neither the Scrum Master nor the Product Owner is required to address every complaint that comes across their desk. Ultimately, if the person voicing the complaint can’t address it openly, then there may be underlying problems of distrust and a lack of communication within the team. If there are issues regarding distrust and communication, then the anonymous complaint is likely secondary to those issues.
Employ Creative Problem Solving – An Agile Developers Best Skill
We’ve already mentioned that creative problem solving and creative thinking are two skills often sought after in Agile Developers and Scrum Masters. It is these two skills that can resolve most conflicts within an Agile Team. However, it may fall on to the Scrum Master or Product Owner to urge the team to use these skills in a different way. Developers will often use creative thinking to their advantage when working on code, looking for elements of a project that could become automated, and building more efficiency into their daily work. Most developers don’t rely on creative problem solving or creative thinking when it comes to interpersonal problems and team conflict.
Walk your team through the four steps of creative problem-solving and apply each of these steps to the conflict at hand.
Clarify—Get to the root of the problem. If it is an interpersonal problem, then you may need to assess the elements of each person’s personality that are leading to conflict. For example, if one team member frequently delivers work later than the team expected it, then the problem could be time management. That individual team member may not realize how long an individual task is going to take them. However, the team’s perception may be that this person is slacking off or making overly ambitious promises. Often the clarification process will be like ripping off a band-aid, the individuals involved may need to be made aware that their perception may be the actual cause of the conflict.
Ideate—Brainstorm and explore how to resolve this conflict. Now working on an Agile team, there are certain “solutions” that are not available. For example, again, with interpersonal problems, it’s not reasonable to have one team member sitting in a separate room or further away from the team because it will ultimately deteriorate the value of the final product. Put your team to work to create ideas and explore what options are available.
Develop—During the ideate process, you may hear frequent groans of, “but that won’t work.” The development step demands that people avoid cutting down ideas and instead workshopping those ideas to make them implementable.
Implement—Implementation is often easier said than done. When you’re to the implementation step, ensure that you build follow-up within your upcoming meetings. That can include your daily standups and your Sprint meetings. Conflict resolution doesn’t stop when you identify a way to resolve the issue. Conflict resolution is complete when the issue is no longer a problem.
Coach Instead of Managing, Facilitate Instead of Directing
Agile team management comes down to coaching and facilitating, while most business practices have taught people they need to manage and direct. It’s true. There are some management tactics involved in both the Product Owner and Scrum Master positions. However, within Agile Teams, it’s very common for a leader to emerge within the Development Team, and the team still not take on a hierarchical structure.
Every member of an Agile Team must be willing to face challenges and conflict together. Coming back to the core of Agile Principles and the values listed within the Agile Manifesto, the team must always put the product in the project in focus. But if the people don’t value each other over the processes and a team structure, then the product won’t be as high quality as it could have been. Ultimately if there are conflicts and tension within the team, it could lead to project failure.
But an Agile team experiencing conflict doesn’t mean it’s on the road to ruin. If anything, conflict is a good sign that the people within the team are working collaboratively. You can take any group of people, and there will always be different perspectives and approaches, so conflict should be expected. As a leader on an Agile Project, you should aim to coach and facilitate the team through any conflict or complaint rather than making decisions for them or issuing orders to resolve the problem.