The introduction of the agile methods has shifted the focus from the individual software developer and instead highlighted team, collaboration, and communication (Cockburn and Highsmith, 2001). In software engineering organizations today, well-functioning teams are considered a critical success factor (Gren et al., 2017). A natural consequence, or a byproduct, of increased collaboration is interpersonal conflict (Gren, 2017).
To obtain well-functioning and autonomous teams, a set of group psychological factors has to be in place. Self-organization of teams has been shown to surface naturally only in the more mature stages of group development, which also implies that the leadership gets more and more shared over time, and many groups do not reach the more mature stages but get instead stuck for a variety of reasons (Wheelan et al., 2003). The group developmental theories state that, when humans organize in small groups to achieve a set of common goals, we go through a specific set of stages and the group members behave differently across these stages (Kozlowski and Ilgen, 2006).
Research on development of small groups agrees on that a period of disagreement and conflict is necessary to reach the better functioning mature stages (Kozlowski and Ilgen, 2006). People in groups need to challenge one another to figure out the group members’ real competences and, also, set the group norms, i.e., the rules of the game (Wheelan, 2005). This implies that some conflict stage is needed for most teams in order to later be more effective, and teams need to create a practical conflict management approach specific for every single constellation of people. Having efficient conflict resolution techniques in agile teams are thus a prerequisite for building a well functioning autonomous team. Therefore, conflict resolution needs to be conducted on team level, which has also been shown in the software engineering context in a study by Ocker (2001). They showed that the group development maturity was positively connected to the quality of work output, and the degree of satisfaction.
In this short paper, we first outline research on work-related conflicts from the information systems and software engineering domain. We then present guidelines taken from conflict resolution research and, finally, we discuss potential gains in the software engineering autonomous teams’ context and suggest future work.
2. Interpersonal Conflict and Software Engineering Research
Traditionally, psychology researchers divide conflicts into the three types (relation, process, and task) based on their content. Still, these types are not well-defined and their link to performance not fully understood (Behfar et al., 2008). As an example, relationship conflicts have been shown to affect both task-based and social aspects of team performance negatively (Manata, 2016). Therefore, there seem to be indications of more complex relationships between conflict types than presented by, for example, Domino et al. (2003) within the software development domain.
A conflict can, in its broader sense, be defined as “the process which begins when one party perceives that another has frustrated, or is about to frustrate, some concern of hers or his” (Thomas, 1992). Therefore, a conflict has nothing to do with raising one’s voice of fighting, even if that is the practical interpretation of the word in some languages, like Swedish.
Information system (IS) researchers have also conducted studies related to conflict. In a study from 2001, Barki and Hartwick (2001) showed that interpersonal conflict consisting of disagreement, interference, and negative emotion had less of an impact on the project outcomes when the teams had well-functioning conflict management (Barki and Hartwick, 2001). Similar results were obtained in that same year by Sawyer (2001).
The research on conflict in software engineering is scarce, which might indicate the difficulty of such inquiries. Among the older studies is the work by Gobeli et al. (1998) where they show that dysfunctional conflict management approaches have adverse effects on results. In a study on requirements specification, interpersonal conflicts were shown to link directly to requirements diversity, which was negatively associated to project performance (Liu et al., 2011). Furthermore, a study by Gren (2017) showed that interpersonal conflict was adversely connected to the agile team practices Iterative Development and Customer Access.
Together, these mentioned studies further motivate the need for proper conflict resolution in agile teams. Therefore, in the following sections, we will present techniques for how software organizations can raise the knowledge of having to manage interpersonal conflict efficiently.
3. Intra- and inter-group conflict
Interpersonal conflict manifests itself often i dyadic relations. A work- or relationship-related conflict needs to be verbally expressed by one person at the time and most often directed to another individual. However, this does not mean that the conflict is isolated to the individuals expressing it (Wall Jr and Callister, 1995). In fact conflicts are seen to be between two parties, be it in individuals, groups or nations (Pruitt, 1969).
Intra-team conflicts, we argue, need a structure to be managed at an early point in time, since conflicts are known to escalate, and sometimes quite severely over time (Pruitt, 1969). Therefore, teams are helped by discussing early conflicts continuously before they become infected and personal. However, if a conflict has escalated, there are expensive knowledge on how to behave in order to solve conflicts fast depending on personal stake, rhetoric, etc. Even is the section below focuses on individuals they techniques can be extended to any two parties (Pruitt, 1969).
4. Escalated interpersonal conflict
In this section, we summarize the content from a number of practical handbooks on conflict management, since we want to provide hands-on tips of how to reason around conflict. It is intended as an introduction to conflict management in practice. For an extensive review of conflict resolution research, we recommend Coleman et al. (2014) that includes almost a thousand pages and hundreds of references to academic papers. We would, again, like to highlight that the conflict resolution needs to be on team-level since they are a prerequisite for getting a team to mature over time.
There is a diversity of situations that potentially can lead to interpersonal team conflict. For example competing needs, fighting about scarce resources, misunderstandings, unclear situations, different views on roles or divisions, different values, norms or understandings, communication problems, competition/rivalry, organizational change, and stress (Coleman et al., 2014; Wall Jr and Callister, 1995).
Having high emotional intelligence is a very useful for successful conflict management. Below is a list of common mistakes that are known to trigger aggressive or unwilling responses in conflict situations (Goleman, 1998; Wall Jr and Callister, 1995):
One perspective — To see the problem only from your perspective.
Poor communication — To stop listening/understanding.
Only binary options — Think “right or wrong;” there’s only one way, and that’s my way.
Correspondence bias — It’s not just the concrete issue that is the problem, it’s the person.
Add new information — Bringing up new information not know to the other party.
Manipulation — Withholding information, talk behind people’s backs.
Hurting purposefully — Finding personal weak spots and attacking.
Ignoring social rules — Stop saying hello, ignore, and exclude from mailing lists.
If successfully avoiding the above mentioned mistakes, and instead recognizing other people’s perspectives and referring to one’s own role in the conflict, trigger much more willingness to find agreeable solutions:
I-message (not iMessage) — Meaning that arguments are more effective if they refer to the person talking instead of the person referring to a set of people or groups not present. Conflict should also be resolved, as a first step, in private using face-to-face communication.
Speak about what you want yourself, not what the other one “should” want. Describe your problem with the other person’s action/behavior and not personality. Listen to the other person and show that you understand the content of what the person is saying. One way of easily achieving this is to verbally interpret what the other person just said, e.g. “if I understand you correctly you mean that…”
Define the problem as a mutual, narrow and specific problem.
Describe your feelings connected to the problem (sad, angry, frustrated, disrespected etc.)
Exchange motives to your positions, what’s behind your different views? What needs to be fulfilled? Listen to each others’ perspectives.
Identify possibilities for mutual benefit by providing many possible solutions, and chose one wisely (Wall Jr and Callister, 1995).
A clearer step-by-step protocol might be the following:
A: Now (What’s the present situation? This is what I/we/they do now)
B: Desired end result (This is how I want it. I/we/they should do like this).
C: Obstacles (Why A instead of B?).
C1: Do we know about the obstacles?
C2: Are the obstacles possible to remove?
C3: Can we remove the obstacles?
C4: Do we want to remove the obstacles?
D: Actions (Suggestions/changes) (Wall Jr and Callister, 1995).
It is important to recognize that different approaches are needed depending on how infected the conflicts are. One significant intervention when conflicts are more complicated is to use a mediator (Moore, 2003). In the agile software development context, the process facilitator (i.e., the Scrum Master in Scrum) would be ideal to take on such a role when needed. Gren et al. (2017) also showed that Scrum Masters often do manage teams in such a way in practice. We recognize that such behavior is not considered to be “pure Scrum,” but argue for the usefulness of having a formal protocol for how agile teams should manage conflict step-by-step in software development organizations.
It is also important to acknowledge that employees have disparate interests in different conflicts. A well-used model of such stance in conflicts was suggested by Thomas (1992), and is shown in Figure 1. Depending on the assertiveness and cooperativeness in each conflict a person will approach the conflict mainly in five different ways (although people tend to resort to some of them more than others). With low assertiveness, i.e., focus on own needs, and low cooperativeness the person will avoid the conflict and maintain their neutrality in relation to the conflict. With high assertiveness and low cooperativeness the person participated by having a zero-sum orientation and assumes that one has to win and the other has to lose. With high cooperativeness but low assertiveness, the person maintain harmony and accede to the other party. With an intermediate level on both assertiveness and cooperativeness, the person will compromise and try to find solutions acceptable to all parties, which also maintains the relationship undamaged. With high levels of both assertiveness and cooperativeness, the person will collaborate, meaning that the person will try to expand the range of possible outcomes and achieve win/win outcomes, which also challenges the relationship more.
There is also a range of cognitive biases that might create conflict that could be avoided (for more examples of such cognitive biases see, e.g., Evans (1989)). The literature on cognitive and biases is vast, and we will only mention one of them in this paper. The one we have chosen that we believe have a significant impact on conflict resolution is the correspondence bias already mentioned in the list above about common mistakes in conflict situations. This bias is known by many names and was first called the fundamental attribution error. This error is about people’s tendency to place an undue emphasis on internal characteristics to explain the behavior of someone else in a given situation, rather than considering external factors, i.e., the tendency to believe that people’s actions reflect who they are (Gawronski, 2004). Therefore, when observing an inappropriate behavior, it is critical to take into account and recognize the situational factors, i.e., not only resort to individual factors, such as personality, to explain the behavior (see Coleman et al. (2014) pp. 502). This further motivates avoiding to turn team-level problems into personal ones.
The human factors are increasingly being recognized by software engineering researchers and practitioners alike (Lenberg et al., 2015). The psychological and sociological aspects have been presented as the missing piece in software engineering education (Yu, 2014). Such approaches to training already exist in other fields and can directly be applied to the software engineering context (see e.g., Shell (2001)).
In the agile manifesto (Fowler and Highsmith, 2001), the value “Individuals and interactions over processes and tools” emphasizes the importance of making human interaction efficient. A core aspect of such interactions is the ability to manage conflict well. In order to build efficient and autonomous teams in software organizations, having a formal structure for conflict resolution would undoubtedly be helpful. Research conducted in the information system (IS) domain has shown that making employees aware of how conflicts work has positive effects (Barki and Hartwick, 2001).
To increase awareness and to raise software organizations’ general understanding of interpersonal conflicts, we suggest that software engineering education should include negotiation and conflict resolution training (Shell, 2001). Since software engineers tend to conduct their work in small groups, we suggest that such training should emphasize the group aspects, i.e., interpersonal conflict in autonomous agile teams should be seen a group-level problem and not as a dyadic problem. We believe a majority of conflicts are not due to individual factors but instead team-related contextual factors such as poor communication, unclear role, or undefined goals. These dissimilarities can, therefore, not be resolved through addressing the individuals involved only, but should instead be managed on a team-level.
As mentioned in the previous section, organizations need to provide agile teams with a well-defined process of how to manage team conflict in the organization, and the Scrum Master role might be appropriate for facilitating this process. If such guidelines are not in place, it will be cumbersome to trust team with the authority they need to set directions for new products.
6. Conclusions and future work
In this position paper, we emphasize the importance of considering conflicts in software organizations. Social science research on group dynamics and team development have repeatedly shown that for a team to reach a productive stage it has to, in an efficient way, be able to manage internal conflicts and disagreements. To increase the software engineering general knowledge on how to handle disagreements within a team, we also suggest that software engineering education should include negotiation and conflict resolution training. In this papers, we have provided initial ideas for what aspects to consider in such training. As an example, we argue that a majority of the conflicts originate from group-related factors and that they, therefore, should be managed using a team-level approach.
- Barki and Hartwick (2001) Henri Barki and Jon Hartwick. 2001. Interpersonal conflict and its management in information system development. MIS Quarterly (2001), 195–228.
- Behfar et al. (2008) Kristin J Behfar, Randall S Peterson, Elizabeth A Mannix, and William MK Trochim. 2008. The critical role of conflict resolution in teams: A close look at the links between conflict type, conflict management strategies, and team outcomes. Journal of applied psychology 93, 1 (2008), 170.
- Cockburn and Highsmith (2001) Alistair Cockburn and Jim Highsmith. 2001. Agile software development: The people factor. IEEE Computer 11 (2001), 131–133.
- Coleman et al. (2014) Peter T. Coleman, Morton Deutsch, and Eric C. Marcus. 2014. The Handbook of Conflict Resolution: Theory and Practice (3rd ed.). John Wiley & Sons, San Francisco, California.
- Domino et al. (2003) Madeline Ann Domino, Rosann Webb Collins, Alan R Hevner, and Cynthia F Cohen. 2003. Conflict in collaborative software development. In Proceedings of the 2003 SIGMIS conference on Computer personnel research. ACM, 44–51.
- Evans (1989) Jonathan St. B. T. Evans. 1989. Bias in human reasoning: Causes and consequences. Erlbaum, London.
- Fowler and Highsmith (2001) M. Fowler and J. Highsmith. 2001. The Agile Manifesto. In Software Development, Issue on Agile Methodologies, last accessed on December 29th, 2006. (Aug. 2001).
- Gawronski (2004) Bertram Gawronski. 2004. Theory-based bias correction in dispositional inference: The fundamental attribution error is dead, long live the correspondence bias. European review of social psychology 15, 1 (2004), 183–217.
- Gobeli et al. (1998) David H Gobeli, Harold F Koenig, and Iris Bechinger. 1998. Managing conflict in software development teams: A multilevel analysis. Journal of Product Innovation Management 15, 5 (1998), 423–435.
- Goleman (1998) Daniel Goleman. 1998. Working with emotional intelligence. Bantam Books, New York.
- Gren (2017) Lucas Gren. 2017. The Links Between Agile Practices, Interpersonal Conflict, and Perceived Productivity. In Proceedings of the 21st International Conference on Evaluation and Assessment in Software Engineering. ACM, 292–297.
- Gren et al. (2017) L Gren, R Torkar, and R Feldt. 2017. Group development and group maturity when building agile teams: A qualitative and quantitative investigation at eight large companies. The Journal of Systems and Software 124 (2017), 104—–119. DOI:http://dx.doi.org/10.1016/j.jss.2016.11.024
- Kozlowski and Ilgen (2006) Steve WJ Kozlowski and Daniel R Ilgen. 2006. Enhancing the effectiveness of work groups and teams. Psychological science in the public interest 7, 3 (2006), 77–124.
- Lenberg et al. (2015) Per Lenberg, Robert Feldt, and Lars Göran Wallgren. 2015. Behavioral software engineering: A definition and systematic literature review. Journal of Systems and software 107 (2015), 15–37.
- Liu et al. (2011) Julie Yu-Chih Liu, Hun-Gee Chen, Charlie C Chen, and Tsong Shin Sheu. 2011. Relationships among interpersonal conflict, requirements uncertainty, and software project performance. International Journal of Project Management 29, 5 (2011), 547–556.
- Manata (2016) Brian Manata. 2016. Exploring the association between relationship conflict and group performance. Group Dynamics: Theory, Research, and Practice 20, 2 (2016), 93–104.
- Moore (2003) Christopher W. Moore. 2003. The mediation process: Practical strategies for resolving conflict (3rd ed.). Jossey-Bass, San Francisco, California.
- Ocker (2001) Rosalie J Ocker. 2001. The relationship between interaction, group development, and outcome: A study of virtual communication. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences. IEEE, 1–10.
- Pruitt (1969) Dean G Pruitt. 1969. Stability and sudden change in interpersonal and international affairs. Journal of Conflict Resolution 13, 1 (1969), 18–38.
- Sawyer (2001) Steve Sawyer. 2001. Effects of intra-group conflict on packaged software development team performance. Information Systems Journal 11, 2 (2001), 155–178.
- Shell (2001) G Richard Shell. 2001. Teaching Ideas: Bargaining Styles and Negotiation: The Thomas-Kilmann Conflict Mode Instrument in Negotiation Training. Negotiation Journal 17, 2 (2001), 155–174.
- Thomas (1992) Kenneth W Thomas. 1992. Conflict and conflict management: Reflections and update. Journal of organizational behavior 13, 3 (1992), 265–274.
- Wall Jr and Callister (1995) James A Wall Jr and Ronda Roberts Callister. 1995. Conflict and its management. Journal of management 21, 3 (1995), 515–558.
- Wheelan (2005) S Wheelan. 2005. Group processes: A developmental perspective (2 ed.). Allyn and Bacon, Boston.
- Wheelan et al. (2003) Susan Wheelan, Barbara Davidson, and Felice Tilin. 2003. Group Development Across Time: Reality or Illusion? Small group research 34, 2 (2003), 223–245.
- Yu (2014) L. Yu. 2014. Overcoming Challenges in Software Engineering Education: Delivering Non-Technical Knowledge and Skills. IGI Global, Hershey, Pennsylvania.