1. Home
  2. Training Library
  3. Module 1 - Understanding Conflict

Agile Means Conflict

Developed with
QA

Contents

keyboard_tab
Managing Conflict in Agile Teams
1
What is Conflict?
PREVIEW1m 58s
2
Types of Conflict
PREVIEW3m 42s

The course is part of this learning path

Managing Conflict in Agile Teams
course-steps
4
description
1
play-arrow
Start course
Overview
DifficultyBeginner
Duration12m
Students203
Ratings
5/5
starstarstarstarstar

Description

Course Description 

This module looks at what a conflict is before investigating the different types of conflict and what they mean for an Agile team. 

Learning Objectives 

The objectives of this course are to provide you with and understanding of: 

  • What conflict is and the Scrum Master’s role in dealing with it. 
  • The differences between conflict, disputes and opposition. 
  • The common types of team conflict. 
  • How teams develop and how conflict can arise in an Agile context. 

Intended Audience 

The course is aimed at the Agile Scrum Master. However, it’s equally relevant to the Product Owner’s role in the team. 

Prerequisites of the Certifications 

There are no specific pre-requisites to study this course 

Feedback 

We welcome all feedback and suggestions - please contact us at qa.elearningadmin@qa.com to let us know what you think. 

 

Transcript

Agile involves teams of people working together. Most of the time this is uneventful and individuals just get on with what they need to, but sometimes things can get a little heated. 

 

Dispute or conflict? 

Take a look at this scenario – is it a dispute or a conflict? 

 

Two developers are in the meeting room with the door shut. You notice that the volume in the room is getting louder…and louder – it’s only 9:30 in the morning so it wakes a few people up. 

 

Max is pointing at the design diagram that Natalie produced the day before. "But you don't need a diagram in agile," you hear him say. He's seemingly not arguing about the technical merits of the design; he just doesn't want anyone on the team drawing any kind of design diagram. 

 

Then you hear Natalie respond by saying "So, how are we supposed to know where to start if we don't have an initial conversation?". To which Miguel irritatingly responds with “I'm not saying you can't have the conversation. Listen to me. You don't need a diagram. The code will tell you what to do." 

 

Then you hear Natalie again, quite exasperated: "But the diagram IS the conversation.” 

 

Then, they both leave the room to get a cup of coffee…on the way you see them making small talk and smiling with each other. 

 

It’s hard to say really, how serious this situation is and, if it was at your place, you’d know the people involved, understand the situation better and would intuitively know if you should be concerned. But the fact they left the room talking together probably means it’s not a long-term issue. 

 

Collaboration and transparency 

The point is, Agile does create conflict. Collaboration means conflict and transparency means conflict. 

 

Whenever more than one person works on a problem there’ll be disagreements – about the approach, the philosophy, the tools and technology used and the personalities involved. The more people that work together the harder it is to reach consensus. 

 

And transparency is important in Agile – this allows problems to surface and be dealt with. Without transparency, issues can fester and grow, and then potentially become impossible to resolve. So, it goes without saying that with transparency comes disagreements, disputes and conflict, both within the team and with external stakeholders. 

 

Conflict is necessary in an agile environment – the trick is knowing how best to deal with it and how much time to invest in resolving it. 

 

Stages of team formation 

Bruce Tuckman developed a well-known model of team formation in the 1960s which is still very relevant today. It focuses on the way a team tackles their tasks during the different stages of development as they progress to becoming a high performing team. 

 

The five stages are forming, storming, norming, performing and adjourning, and we’ll go through what each of these mean. As we do, think about the teams you’ve worked in: 

  • Do you recognize these traits? 

  • Did all your teams reach the ‘performing’ stage? 

 

The forming stage is when the team is assembled and the task is allocated. Here, team members tend to behave independently and, although they’re happy to be in the team, they don’t know their colleagues well enough to unconditionally trust each other. Time is spent planning, collecting information and bonding. 

 

The storming stage is when the team starts to address the task and suggest ideas. These ideas may compete with each other and, if not managed well, this stage can be destructive for the team. Relationships between team members will be made or broken when they’re ‘storming’ and some may never recover. In extreme cases the team can become stuck in this stage. 

 

If a team is too focused on reaching consensus and perhaps avoiding conflict, they might agree an ineffective solution just to maintain harmony. This needs to be avoided through strong facilitative leadership. 

 

At this stage, the team’s effectiveness is low as they work through the ways of operating and the team dynamics. 

 

As the team moves out of the storming stage, they enter the norming stage. This involves more harmonious working practices with individuals agreeing the rules and values they operate through. Teams might start to trust themselves during this phase as they accept the contribution of each member.  

 

Team leaders can often take a step back here as individuals take greater responsibility. However, the risk during the norming stage is that the team become complacent and lose their creative edge or the drive that got them there. 

 

The performing stage is where the team is high-performing and delivering continual value through independence, motivation, knowledge and competence. Not all teams make it to this stage. 

 
In high-performing teams, decision making is collaborative, and disagreements and disputes are both expected and encouraged, through a high level of respect and communication between team members. 

 

The final adjourning stage is about the end of a project and the breakup of the team. 

 

What does this all mean? 

Agile teams will work through these stages when they start a new project or task. The start point will depend on how long the team has been together and the work they’re doing. 

 

Scrum Masters need to understand that high-performing agile teams will face conflict and this should be welcomed, particularly as they reach a peak level of efficiency and productivity.  

 

You also need to appreciate that, as new members join the team, there’s a full or partial reversion back to the forming stage. Think about a situation where a new senior internal stakeholder joins a team – the team members would understandably need to clarify objectives, know the stakeholder’s perspective and learn to trust their new colleague.  

 

Tuckman’s model doesn’t give you the answers to everything, but it helps to explain some important team dynamics and provides the basis to manage conflict situations. 

 

There’s more information about Tuckman’s model in the ‘Forming, Storming, Norming and Performing’ guide. You’ll find the link in the Managing Conflict Resources. 

About the Author
Students2957
Courses36
Learning paths9

Tony has over 20 years’ experience in Business Development, Business Change, Consulting and Project/Programme Management working with public, private and third sector organisations.

He has helped organisations to design and create process and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider utilising a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.

As a confident and self-motivated professional with excellent communication skills Tony is able to bring people together and get them working as a team quickly.

Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Programme and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers and worked at Director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.