Supporting Emotional Intelligence, Productivity and Team Goals while Handling Software Requirements Changes
Article No.: 153, Pages 1 - 38
Abstract
Background: Research shows that emotional intelligence (EI) should be used alongside cognitive intelligence during requirements change (RC) handling in Software Engineering (SE), especially in agile settings. Objective: We wanted to study the role of EI in-depth during RC handling. Method: We conducted a mixed-methods study (an interview study followed by a survey study) with 124 software practitioners. Findings: We found the causal condition, intervening condition and causes lead to key direct consequences of regulating own emotions, managing relationships, and extended consequences of sustaining productivity, setting and sustaining team goals. We found several strategies of supporting EI during RC handling. Further, we found strong correlations between six strategies and one being aware of own emotions, regulating own emotions, sustaining team productivity, and setting and sustaining team goals. Conclusion: Empathising with others and tracking commitments and decisions as a team are key strategies that have strong correlations between managing emotions, between sustaining team productivity, and between setting and sustaining team goals. To the best of our knowledge, the framework we present in this paper is the first theoretical framework on EI in SE research. We provide recommendations for software practitioners to consider during RC handling.
1 Introduction
Software requirements changes (RCs) - additions/modifications/ deletions of functional/non-functional requirements in software products [17] are inevitable, and they influence the emotions of software practitioners who handle them [18, 19, 20]. The influence of RCs on software practitioners’ emotions occur throughout the entire RC handling life cycle [19], and at specific milestones of receiving, developing and testing, and delivering [18]. For better handling of RCs, it is necessary to have agility – in such settings (carrying out agile practices such as collaboration, self–organisation, and cross–functionality [19]), cognitive intelligence (one’s abilities to learn, remember, reason, solve problems, and make sound judgements, particularly as contrasted with emotional intelligence [27]), and emotional intelligence (EI; type of intelligence that involves the ability to process emotional information and use it in reasoning and other cognitive activities [27]) in synergy [19].
As the final part of a four-study series focusing on emotional responses to RCs (part 1: [20], part 2: [18], part 3: [19]), we conducted the study reported in this paper to deeply understand the role of EI in handling RCs in software engineering (SE), in order for practitioners to have a better RC handling experience. To the best of our knowledge, this is the very first study on EI in handling RCs in SE. To conduct this study, we followed a mixed-methods approach. First, we conducted 18 semi-structured interviews1 (Step 1), and a broad survey2 of 106 participants (Step 2). Our interview study was followed by a Socio-Technical Grounded Theory (STGT) analysis, where data collection and analysis were done in an iterative and interleaved fashion on the common grounds of RC handling. The first iteration of our interview study consisted of 10 interviews with a broad focus on RCs and emotional responses to RCs (approximately 60 minutes each). The second iteration consisted of the remaining 8 interviews with a specific focus on EI (approximately 30 minutes each). Both iterations of interviews included a pre-interview questionnaire (approximately 30 minutes to fill) that focused on participant demographics, and the context of the participants’ RC handling scenario. Through the STGT analysis, we found key causes (being aware of own emotions, being aware of others’ emotions), consequences (regulating own emotions, managing relationships, sustaining productivity, setting and sustaining team goals), 2 conditions, 12 strategies, and 3 covariances of practitioners’ EI when handling RCs. The covariances found were among strategies, causes, and consequences.
For the developer community to use our insights practically at work and also for researchers to gain an in-depth understanding of our central phenomenon, which is EI in RC handling, we decided to verify the relationships we found between each strategy and cause, and each strategy and consequence, and further explore the existence of any other relationships. Having such a set of strategies for practitioners to use will assist them have a more positive experience in handling even challenging RCs. Therefore, we conducted a broad survey study and studied the correlation between the strategies and causes, strategies and consequences using inferential statistics (Spearman’s rank correlation coefficient test). We were able to identify strong correlations between setting and sustaining team goals and six strategies, sustaining team productivity and four strategies, regulating own emotions and two strategies, and being aware of own emotions and one strategy. Through the survey study, we also identified six relationships that we found in the interview study (between regulating own emotions and four strategies, and managing relationships and two strategies) were not statistically significant.
The key contributions of this work include:
—
A large scale survey and interviews of practitioners focusing on the role of Emotional Intelligence during Requirements Change handling;
—
A novel set of practical recommendations, including strategies that practitioners can use to have better RC handling experience with EI; and
—
Key future research directions for SE researchers around emotion-oriented human aspects in SE.
The rest of this paper is structured as follows. Section 2 introduces key definitions, background, and motivation of the study. Section 3 describes our mixed-methods study design, and Section 4 presents our interview study, including approach and its findings. Section 5 describes our Survey study approach and its findings, and Section 6 discussed this study’s overall key findings and implications for practice and research. In Section 7 we briefly discuss an evaluation of the STGT method application and limitations of this study, and finally in Section 8 we draw key conclusions of the study.
2 Background and Motivation
2.1 Definitions
We use some specialist terminology throughout our paper. We define them as below (cited definitions are from direct sources, and uncited definitions are our own). The terms are listed in their order of appearance in the paper.
—
Emotion: A sequence of interrelated, synchronised changes in the states of all the five organismic subsystems (information processing, support, executive, action, and monitoring) in response to the evaluation of an external or internal stimulus event as relevant to central concerns of the organism [25]
—
Emotional intelligence: Type of intelligence that involves the ability to process emotional information and use it in reasoning and other cognitive activities [27]
—
—
Emotional response: An emotional reaction, such as happiness, fear, or sadness, to give a stimulus [27]
—
Empathy: Understanding a person from his or her frame of reference rather than one’s own, or vicariously experiencing that person’s feelings, perceptions, and thoughts [27]
—
Central phenomenon: The focus of the study [7]
—
Context: This is where the central phenomenon took place. This includes participants’ demographics, and their team and project information [7]
—
Condition: A factor that affects the central phenomenon [7]
—
Causal condition: The condition under which the cause gave rise to the central phenomenon [7]
—
Intervening condition: A condition that alters the central phenomenon in some way [26]
—
Cause: This results in the central phenomenon [7]
—
Consequence: The output of the cause [7]
—
Direct consequence: The immediate output of the cause
—
Extended consequence: The immediate output of the direct consequence
—
Contingency: Any event that can occur given a specific cause or condition [7]
—
Strategy: An action that can be executed
—
Variable: Context, condition, cause, consequence, or contingency which are the elements of the central phenomenon [7]
—
Covariance: The change of one variable with another [7]
2.2 Background
2.2.1 Requirements Change Handling.
Agile methods are widely used in software engineering contexts and promote the idea of introducing RCs even late in development [4]. However, software practitioners encounter many challenges such as lack of requirements traceability [11], incorrect requirements prioritisation [11], minimal requirements documentation [5, 11, 13, 17], contractual issues [11], and customer agreement [11] in handling these new RCs.
In our earlier work we found that RCs in agile contexts are challenging to handle. Key influences included when their complexity is high, cascading impact is high, size is large, the effort required is high, the definition is imprecise or unclear, the priority is high, the access to customer is difficult or irregular, and the cross-functionality is forced [19]. There are many practices investigated or proposed to handle some of these issues, e.g., face–to–face communication [2, 3, 6, 12] iterative requirements [1, 6, 12, 23], prototyping [1, 23, 28], review meetings [6, 23], and prioritisation [1, 6, 23]. Table 2 outlines other techniques that are available to mitigate these challenges and handle RCs. However, our earlier studies showed that most of these challenges result in varying emotional responses in software practitioners [18], Madampe2023AEngineering. From some of our earlier study feedback of team leads and practitioners, [18], we began to surmise that how practitioners handled their emotions in these varying circumstances – i.e., aspects of their emotional intelligence – could be a key factor in how well, or poorly, they both handled changes and worked with their teams to handle them. High emotional intelligence typically includes the ability to identify, understand and manage one’s emotions in positive ways to communicate effectively, empathise with others, defuse conflict, and manage stressful situations.
Table 1.
| P# | Country | XT | XTA | Agile Methods Experience | Role in the Project |
|---|---|---|---|---|---|
| P1 | NZ | 20 | 12 | Scrum, XP, Scrum XP combo, Kanban, FDD, Scrumban | Tester/ Scrum Master |
| P2 | NZ | 56 | 16 | Scrum, XP, Scrum XP combo, Kanban | Manager |
| P3 | NZ | 24 | 4 | Scrum, Kanban | Business Analyst |
| P4 | AU | 25 | 8 | Scrum, XP, Kanban, FDD, DSDM | Global Head of Projects |
| P5 | NZ | 15 | 4.6 | Scrum, XP, Scrum XP combo | Scrum Master |
| P6 | NZ | 26 | 1 | Scrum | Scrum Master |
| P7 | NZ | 3 | 2 | Scrum, Kanban | Scrum Master |
| P8 | NZ | 19.5 | 18 | Scrum, XP, Scrum XP combo, Kanban, Spotify, Company methods | Senior Solutions Architect/ Principle Architect |
| P9 | NZ | 7 | 5 | Scrum, Kanban, FDD | Tester |
| P10 | AU | 2 | 2 | Scrum, Kanban | Scrum Master/ Business Analyst/ Manager |
| P11 | SG | 6 | 4 | Scrum | Developer/ Product Owner |
| P12 | SL | 3 | 3 | Scrum, Scrum and XP combo, Kanban | Agile Coach/ Scrum Master |
| P13 | AU | 8 | 8 | Scrum, Scrum XP comobo, Kanban, FDD, Spotify, Waterfall | Manager |
| P14 | AU | 11 | 11 | Scrum, Kanban, Waterfall | Developer |
| P15 | AU | 6.5 | 6.5 | Scrum | Manager |
| P16 | AU | 19.5 | 10 | Scrum, Kanban, FDD, Waterfall | Manager/ Developer/ Tester |
| P17 | AU | 3.5 | 3.5 | Scrum, TDD | Developer |
| P18 | AU | 4 | 4 | Scrum, Kanban | Developer |
Table 2.
2.2.2 Emotional Intelligence.
There are several definitions for EI. Salovey and Mayer, who proposed the concept of EI, define it as “a type of intelligence that involves the ability to process emotional information and use it in reasoning and other cognitive activities” [27]. This concept was made popular by Daniel Goleman, who proposed in his work with his colleagues [8] the key aspects of EI, such as self-awareness – awareness of own emotions, social awareness – awareness of others’ emotions, self-management – regulating own emotions, and relationship management – managing relationships. The findings on causes and direct consequences we present in this paper were named using these four aspects. As researchers found assessing EI is worthy of attention, several EI assessment measures currently exist. These EI measures fall into ability–based or mixed–based model categories. The EI measures that are currently available and their details are summarised online,3 hence we do not explain about them here.
In our earlier work we found that agility (in such settings), cognitive intelligence, and EI of SE practitioners need to be used together to handle RCs effectively [19]. Studies focusing on agility and cognitive intelligence are prominent in Software Engineering research. However, studies focusing on EI are very limited ([15, 24]). Kosti et al. [15] show that there are connections between the EI of the developers and their work preferences. Their studies suggest that people with higher EI prefer being responsible of the entire development process and like to prioritise the tasks by themselves rather than a manager doing that for them. According to [24], the influence of EI on software developers’ stress is negative, and EI fosters trust among developers. As yet, there exist no studies focusing exclusively on EI during RC handling.
2.3 Motivating Example
Consider Kash, who is a developer in a software team. She receives a new RC to work with her colleagues. Because the change was unexpected and impacts her current work, she feels frustrated about this new work (awareness of own emotions). She also perceives that for similar reasons her teammates are also frustrated (awareness of others’ emotions). She then thinks it is better to share how she feels with her team during their retrospective meeting (a strategy for being aware of own emotions, and regulating own emotions). She understands that she has to be open to new RCs as she is working in a software development context (a strategy to regulate her own emotions). She also thinks that if herself and her team have open and regular communication about new RCs then it will help everyone to bond and have better relationships within the team (a strategy to manage team relationships). Furthermore, she finds that these approaches allow her to sustain her own productivity within the team, but also to set and sustain team goals.
3 Study Design
Our study followed a mixed-methods study design (Figure 1). First, we conducted an interview study to gain an in-depth understanding of the role of EI in handling RCs in SE. Then, we conducted a broad survey study to verify some relationships (between strategies and causes, and strategies and consequences) in the interview study and explore if there are more relationships that we did not find in the interview study. The approaches we took in the two studies are given in-detail in Sections 4 (interview study) and 5 (survey study). More details including the limitations of the mixed-methods approach are given in Section 7. The instruments we used in this study are available in the online replication package.4
4 [Step 1] Interview Study
4.1 Interview Study Approach
An overview of our interview study approach is given in Figure 2. We collected data from practitioners in Australia, New Zealand, Singapore, and Sri Lanka in two iterations. The first iteration was to gain a high level understanding of general issues in RC handling and emotional responses to RCs. The second iteration was to provide a finer focus on emotional intelligence. We used socio–technical grounded theory (STGT) [10] techniques such as open coding, constant comparison, and memoing to analyse the data. The steps we followed consisted of developing the study protocol (pre–interview questionnaire development, interview guide formation), conducting a pilot study, collecting data, and analysing data. We elaborate on these steps in the following sub–sections.
Fig. 2.
4.1.1 [Step 1.1] Interview Protocol Development.
Pre–interview Questionnaire Development. We collected participants’ demographics (Section 4.3), team, and project information (Section 4.3), through a pre–interview questionnaire. Having a pre–interview questionnaire helped us gain a better understanding of the participants and the context they are planning to discuss in the interviews in advance, and also allowed us to have enough time to focus the interview on the RC handling situation. The questions in both iteration pre–interview questionnaires were the same, except that the second had an additional question about the impact of Covid–19 on RC handling, and an EI scale. All the pre–interview questions were mandatory and close–ended except for the question on Covid–19, which was an optional open–ended question. The approximate time spent on filling the pre–interview questionnaire per participant was 10 minutes in the first iteration and 30 minutes the second. As we recruited participants from a software company in the second, we had an additional step where a senior management level employee reviewed the pre–interview questionnaire to ensure the questions were in line with company policies.
Interview Guide Design. To get an in–depth understanding of the role of EI in handling RCs, we collected qualitative data through semi–structured interviews. One advantage of conducting interviews was the ability to ask the participants follow-up questions, which is a limitation in open–ended questions in surveys. To guide our interviews, we designed the interview guides (one for each iteration) with an estimated time of 60 minutes and 30 minutes, respectively. The first iteration interview guide focused on general issues of emotions experienced during RC handling, and the second focused solely on EI during RC handling.
In our first interview iteration we started the interview by asking the participants to walk through a scenario where they had RCs, and then we asked follow-up questions such as “how did you feel when you received the RC?” and so on. As the study progressively focused on EI, in the second iteration of interviews we included questions to cover the four aspects of EI as defined by Goleman et al. [8], i.e., self-awareness, self-management, social awareness, and relationship management. This was done to ensure the proper treatment of EI as defined in Psychology. However, the actual terms were not used in the interview questions and interviewees were allowed to express their experiences freely. Therefore, in our second interview guide we first asked the participant to describe the situation that they used when answering the pre–interview questionnaire. Then we designed the rest of the questions to elicit more data to answer our research questions. For example, the starting question “Let’s talk about the RC handling situation you used to answer the questions in the pre–interview questionnaire. Can you describe it for me?” followed by questions such as “how did that make you feel?,” “what did you do to manage how you felt?,” “how did your teammates react?,” “how did you work as a team in that situation?,” “what could have been different for you not to experience so?” (if the situation was challenging) and “how did the feelings you had affect the progress of working on that RC?.” We also prepared a slide with a list of emotions, similar to [18], to help participants recall how they felt in answering questions related to how they felt when handling RCs.
Explanatory Statement and Advertisement Preparation. Explanatory statement. In both iterations, we documented the details of the study in a statement in which we explained what the participants are expected to do, and further crucial information such as the impact of participation/non–participation/withdrawal of participation in the study, and confidentiality.
Advertisement. We designed an advertisement to gauge the interest of potential participants. The advertisement provided a high level view of the study. As our second iteration of interviews focused on EI, both the advertisement and the explanatory statement avoided the words “emotions” and “intelligence” to reduce the drop–rate of potential participants and any biases that could occur when answering the questions.
4.1.2 [Step 1.2] Transitional Piloting.
As we transitioned from the first set of interviews asking more generally about emotions when handling RCs to a deeper focus on EI, we decided to pilot our revised protocols with an industry practitioner. An experienced software architect from Sri Lanka helped us pilot our revised protocols. It became apparent that if the pre–interview questionnaire was filled in advance, the participant was likely to forget it by the interview time. Due to this experience, we decided to ask the participants in our study to fill in the pre–interview questionnaire an hour before the scheduled interview time. This made us change our initial scheduling plan by having two blocks scheduled for the participants – one to fill in the pre–interview questionnaire, and the other for the interview.
4.1.3 [Step 1.3A] Data Collection.
The study commenced with the use of convenience sampling and later moved to using theoretical sampling.
Participant Recruitment. In our first iteration of interviews we made an open call by sharing the advertisement with the explanatory statement on social media such as LinkedIn, X (formerly known as Twitter), and Facebook. We recruited ten participants in this iteration. In the second iteration we sent the same artefacts (but with different content) to personal contacts and also recruited six participants from a large software company (the other two participants worked at different companies). An employee who works at this company shared the advertisement and the explanatory statement with the potential participants. They also helped in scheduling the pre–interview questionnaire filling time and interviews. The participant demographics, project and team information, and the scenarios participants used in the study are given in Section 4.2.
Distribution of the Pre–interview Questionnaire. The first author shared a link to the pre–interview questionnaire with potential participants who showed their interest in participating in the study one or two days before the interview. In our first iteration of interviews, the pre–interview was hosted on Google Forms at The University of Auckland. Our second pre–interview questionnaire was hosted on Qualtrics at Monash University. The first author made sure that pre–interview questionnaires were not filled way ahead of the interview, but only just before the interview, by checking Google Forms and Qualtrics. We deliberately chose to use this approach so that the participants didn’t have to spend the first few minutes of the interview recalling about an RC handling experience they used in a (much) earlier pre–questionnaire.
Conducting Semi–structured Interviews. For the first iteration of interviews, the first author conducted the seven interviews face–to–face, and three interviews online (Skype). In our second iteration of interviews, the first author conducted all the interviews online (Zoom) with the participants due to the Covid–19 pandemic. The average time spent on interviews remained the same as we planned (60 minutes and 30 minutes, respectively).
4.1.4 [Step 1.3B] Data Analysis.
The audio-recorded interviews were transcribed by the first author and a professional transcriber under confidential agreement. For our second iteration of interviews, we also used otter.ai5 to transcribe the interviews. Furthermore, MAXQDA6 was used to analyse the qualitative data. We analysed the qualitative data collected from the interviews and from the open–ended question on Covid–19 using open coding and constant comparison techniques in Socio–Technical Grounded Theory (STGT) [10]. We used STGT data analysis techniques as STGT is designed to uncover the insights in socio–technical environments, and due to positive experience using it in our previous studies [18, 19].
Open Coding and Constant Comparison. Figure 3 shows an example of STGT analysis. In this example, the raw data “Open and honest communication always and pulling people up when there’s any type of emotion” resulted in the code “Open [+honest] and regular communication [motivate when having negative emotions] with others,” which is the researcher’s interpretation of data in small chunks of meaningful words. These codes were then constantly compared, and similar codes were grouped to develop the concept “Open and regular communication.” The same constant comparison technique was applied to the concepts to come up with the category “Strategies.” A summary of the findings coverage by participants is given in Table 8 in Appendix A.
Table 3.
| P# | Scenario used in the study | Causal condition (RC handling) | Intervening condition (mode of work) |
|---|---|---|---|
| P1 | Modifying a function after a customer requesting something different from what was being started but was still aligning with sprint goal | Modification | In–person |
| P2 | Modifying a function | Modification | In–person |
| P3 | Modifying a function | Modification | In–person |
| P4 | Adding new features to increase the business value after a market analysis | Addition | In–person |
| P5 | Modifying a function | Modification | In–person |
| P6 | Modifying a function | Modification | In–person |
| P7 | Late addition of a missed requirement | Addition | In–person |
| P8 | Modifying a feature after a release | Modification | In–person |
| P9 | Modifying a function after a customer requesting something different from what was being started in the middle of a sprint | Modification | In–person |
| P10 | Adding a new feature after requesting a feature request | Addition | In–person |
| P11 | Removal of features that end users no longer require | Deletion | Remote |
| P12 | Adding multiple new requirements to upgrade an existing system | Addition | In–person |
| P13 | Discovering new edge cases during development | Addition | Remote |
| P14 | Working on a modification due to a requirement that incepted considering only the ideal product/ design case but not considering the realities of engineering | Modification | Remote |
| P15 | Removal of a no longer necessary requirement that caused engineering dilemmas | Deletion | Remote |
| P16 | Working on a modification due to the development of a requirement based on wrong assumptions | Modification | Remote |
| P17 | Requirement was a workaround for customer requirement and not exactly what customer requested which also resulted in a new requirement instead of the workaround | Deletion + Addition | Remote |
| P18 | Enhancing the product to include a new requested requirement | Addition | Remote |
Table 4.
| Covariance | A | B | C | ||||
|---|---|---|---|---|---|---|---|
| Strategies | Causes | Direct consequences | Mode of work | ||||
| Being aware of own emotions | Being aware of others’ emotions | Regulating own emotions | Managing relationships | Remote working | In–person working | ||
| S1 | Sharing how individuals feel with manager/peers (one-to-one/many) |  | | ||||
| S2 | Open and regular communication (many-to-many) | | | | | Difficult | Easy |
| S3 | Building personal rapports with others | | | ||||
| S4 | Empathising | | Difficult | Easy | |||
| S5 | Being open to RCs | | |||||
| S6 | Focusing on learning from the RC | | |||||
| S7 | Pre/post control of expectations about RC | | |||||
| S8 | Understanding/using the level of autonomy individual has over RC implementation | | |||||
| S9 | Tracking commitments and decisions | | Easy | Difficult | |||
| S10 | Having a dedicated lead for RC | | |||||
| S11 | Having team/social rituals | | | ||||
| S12 | Working as a single cross-functional team | | | ||||
Table 5.
| Decomposition of S1 to granular level experience factors | |
|---|---|
| Before | After |
| S1. Sharing how individuals feel with manager/ peers (one-to-one/many) | S1a. I shared how I felt with my manager (one-to-one) |
| S1b. I shared how I felt with my peers (one-to-one) | |
| S1c. I shared how I felt with my team in group settings | |
| Replication of Con3 to reflect both individual and team levels | |
| Before | After |
| Con3. Sustaining productivity | Con3a. I maintained a good level of productivity |
| Con3b. As a team, we maintained a good level of productivity | |
| Final set of experience factor statements after arranging at individual and team levels | |
| Individual | Team |
| C1. I was aware of the emotions felt | Con3b. As a team, we maintained a good level* of productivity |
| C2. I was aware of the emotions of others in my team felt | Con4. As a team, we set up and maintained team goals* |
| Con1. I managed my emotions | S9. As a team, we tracked commitments and decisions |
| Con2. I maintained good relationships with others in my team | S10. We had a dedicated lead for RC |
| Con3a. I maintained a good level* of productivity | S11. We had team/social rituals |
| S1a. I shared how I felt with my manager (one-to-one) | S12. We worked as a single cross-functional team |
| S1b. I shared how I felt with my peers (one-to-one) | |
| S1c. I shared how I felt with my team in group settings | |
| S2. I openly and regularly communicated about the RC with others working on the RC | |
| S3. I built personal relationships with others working on the RC | |
| S4. I empathised with others | |
| S5. I was open to RCs | |
| S6. I focused on learning from the RC | *The following definitions were provided to the participants: |
| S7. I controlled my expectations about the RC | good level = moderate to high |
| S8. I understood and used the level of autonomy over the implementation of RC | maintained team goals = didn’t give up the goals |
Table 6.
| Strategy | Individual | Team | ||
|---|---|---|---|---|
| C2. Being aware of others’ emotions | Con1. Regulating own emotions | Con3b. Sustaining team productivity | Con4. Setting and sustaining team goals | |
| S3. Building personal rapports with others |  | |||
| S4. Empathising with others | | | | |
| S6. Focusing on learning from the RC | | |||
| S7. Controlling expectations about RC | | |||
| S9. Tracking commitments and decisions as a team | | | | |
| S10. Having a dedicated lead for RC | | | ||
| S11. Having team/social rituals | | | ||
Table 7.
) and Survey Study (
) (Highlighted: Relationships Found in the Interview Study but Found as Not Statistically Significant in the Survey Study; None: p-value \(\gt\) \(\alpha\) of 0.05)Fig. 3.
Memoing. Memos were written in detail as interview reflections (See below for an example). Conceptual memos (See below for an example) were written throughout the data collection and analysis process. Memoing helped in identifying relationships between categories. All findings were then visualised in Miro7 (visual memo).
Interview Reflection (Written right after the interview with P17)
The participant is a new recruit. They said they got confused when changes happen last minute. Also, relaxed when a requirement which was not exactly what customer requested got removed. They also appreciated “transparent communication”, which is the open communication that everyone talked about. Openness seems to be contributing a lot to keep the participants positive during requirements change handling. Open communication seems to belong to both own emotion regulation and managing relationships. The participant likes to work remotely - has joined the company remotely as well. They believe that information losses are prevented when working remotely as all decisions, and all communications, are recorded (recording decisions). P13 mentioned documenting all details on RCs as well. Documentation seems to be important in all cases. They also mentioned with date shifts, the feature lead is especially anxious. P16 is a feature lead, and they talked a lot about date shifts. But as P16 is an experienced person, according to what they said, they seem to be handling the negative emotions well as they accept the concept of RCs, and use open communication. The key ideas at this point by looking at all interviews conducted up to now during iteration 2 are, accepting RCs as a natural phenomenon helps to regulate one’s own emotions, open communication helps to regulate one’s own emotions and enhances better relationships within the team and beyond, and all teams involved from various disciplines working as a single cross-functional team helps maintain the positivity as an individual/as an organisation.
Conceptual Memo (Written about the condition: Mode of work)
There are pros and cons of remote and in–person RC handling. Empathising is difficult in remote working, but easy when handling the RCs in–person. Empathising is used as a strategy in being aware of others’ emotions. Similarly, “enables recording decisions” is a pro in remote RC handling and “losing information in decision making” is a con in in–person RC handling. But recording decisions is a strategy used to manage relationships. The same applies to open communication. So, the mode of work intervenes in the execution of the strategies.
Output of Interview Study – A Theoretical Framework. Together, the above led to the development of a theoretical framework presented in Figure 4. To visualise our framework, we consulted Glaser’s six Cs model [7] and Strauss and Corbin’s paradigm model [26].
Fig. 4.
4.2 Overview of Interview Study Findings
Within the context of software teams in Australia, New Zealand, Sri Lanka, and Singapore, we found conditions, causes, consequences, contingencies or strategies, and covariances, which altogether are the six Cs of software practitioners’ Emotional Intelligence during Requirements Change handling. The six Cs are shown in Figure 4. Context is the key contextual information about our participants, in this, their work locations, team and organisational contexts of their work. Conditions: Causal conditions are the handling of RCs by practitioners, and intervening conditions are the mode(s) of work by practitioners. Causes and direct consequences: there are four aspects of Emotional Intelligence as defined by Goleman et al. [8]. We used to name these concepts, and we depict these on different sides of the central phenomenon using the relationships among them: awareness of ones own and others emotions (causes) influence direct consequences of emotional regulation and relationship management. These causes also influence (to different degrees) extended consequences of productivity sustainability, team goal setting, and team goal sustainability. We identified 12 Strategies that teams employ that vary with causes, direct consequences and that vary in ease of implementation depending on our identified intervening conditions (work mode).
In the following subsections we first we explain the Context, then the causal and intervening Conditions, and after that the key Causes and Consequences. We describe our 12 identified Strategies, and finally the Covariances influencing which strategies are used, when used, and how easy or hard they are to execute.
4.3 Interview Findings – Context
Participant Demographics. Eighteen software practitioners participated in our study. We had an equal number of participants from Australia and New Zealand (n = 8; 44.44% each). The remaining two participants were from Sri Lanka and Singapore. 10% (n = 6) of our participants played more than one role in their projects. They included managers and Scrum Masters (n = 5; 27.78% each); developers (n = 4; 22.22%); and other roles such as Business Analyst, Product Owner, Tester, Senior Solutions Architect/Principle Architect, and Global Head of Projects. They had a mean total experience of 14.39 years (min–total–experience = 2 years; max–total–experience = 56 years), and a mean agile experience of 6.81 years (min–agile–experience = 1; max–agile–experience = 18 years). The detailed demographic information of the participants is given in Table 1.
Participants’ Team and Project Information. While all of our participants were working in team contexts, they used examples from their current/most recent projects to share their experiences with us. All participants used agile methods in their projects. The team and project information are summarised in Table 2.
4.4 Interview Findings – Conditions
Our findings indicate that the EI of practitioners during RC handling comes to play under the causal and intervening conditions. The causal condition we found was software practitioners handling RCs, and the intervening condition we found was the mode of work.
Causal Condition: Practitioners Handling RCs. –Shared by all participants.
When filling the pre–interview questionnaire, each participant used a specific RC handling scenario from their current or most recent software development project. These scenarios caused several emotional responses in them, and emotions of others around them, which they became aware of, regulated the emotions, and managed the relationships. Hence, practitioners’ handling of RCs is the causal condition of our study. The majority of their scenarios were about modification of requirements (n = 9), and the rest were additions (n = 6), deletions (n = 2), and a combination of a deletion and an addition (n = 1). The summary of scenarios used by the participants and the causal condition derived from the scenarios are given in Table 3.
Intervening Condition: Mode of Work. –Shared by P11–P18.
Table 3 indicates the modes of work (in–person, and remote) of our participants, which we captured through the pre-interview questionnaire. The majority of our participants worked in–person (n = 11) and the rest worked remotely (n = 7). There was no hybrid work at the time of data collection. Our STGT analysis shows that the mode of work intervenes in the execution of the strategies, hence it is an intervening condition. For example, remote work makes it difficult to have open and regular communication, but in–person work makes that easy. For instance,
“I think the face to face has more high bandwidth. But there are lots of circumstances where remote or just not real time is more efficient and more effective. I think, in difficult conversations I prefer face to face. I think it’s easier to have a difficult conversation face to face...” – P13
Similarly, empathising with others is claimed to be more difficult when working remotely, and easier when working in–person. On the other hand, tracking commitments and decisions is claimed to be easier in remote work and more difficult when working in–person. As P17 said,
“So the communication is pretty transparent. Now that we’re doing this remotely. Because it can track any sort of communication that we’re doing with the decision making and reasoning. So we always have Zoom recordings, so that they are decision driven meetings. Also there are like Slack conversations like there are team channels where there is like a lot of to and fro between people who are making the important decisions. And so the rest of the team you can also be about, the reasoning why these decisions are being made as well. So in terms of data being transparent, I feel it’s much more better when we’re doing it remotely, rather than in person when we just have meetings and boards and all. Sometimes there’s no note taker, or sometimes we are not actually recording it. So there are no meeting notes to refer back to. So a lot of times important information stages get forgotten after some point in time, but when you do it remotely, you have like an entire history of conversations that happen in the decisions.” – P17
4.5 Interview Findings – Causes and Consequences
EI is the ability to process emotional information and use it in reasoning and other cognitive activities. We identified being aware of one’s own emotions, and being aware of others’ emotions, as the causes; and regulating own emotions, and managing relationships, as the direct consequences of the causes. Additionally, we identified sustaining productivity, and setting and sustaining team goals, as extended consequences. In this section, we describe causes and consequences together, and extended consequences separately.
Cause: Being Aware of Own Emotions and Direct Consequence Regulating Own Emotions. –Shared by all participants.
Software practitioners feel a wide range of emotions when handling RCs. These span across both high and low pleasurable emotions [18]. The common emotions our participants mentioned that they feel during RC handling were excited, at ease, calm, content, relaxed, anxious, annoyed, frustrated, nervous, stressed, and depressed. Additionally, some participants mentioned the intensity of the emotion they felt, such as very mildly anxious. This indicates that the participants had an awareness of their emotions.
Apart from the emotions they felt, they also mentioned why it is important to be aware of their own emotions when handling RCs. These include: (a) understanding that emotions are influenceable/inheritable, (b) understanding that it is not necessary to expresses negative emotions always, and (c) not allowing own negative emotions to impact team goals; which are collectively, regulating own emotions. For example,
So when the team is anxious, I also get a little bit anxious, I need to hide that and sort of address the issue with the excitement and energy that I have. Because if I address a team being anxious, the team will sort of inherit that and they will start being very reactive. And they might even not show up for a daily Scrum if they get like that – P12
Our participants stated that emotions influence their communication with others through the tone, especially in the case of seniors in the team, as they influence others via communication such as talking. Also, their actions have an outsized impact on subordinates in the team; therefore, it is important to be aware of own emotions to mitigate inheritance of negative emotions.
I’ve seen the value that having someone who is particularly someone more senior in the project who is aware of their feelings, has been able to guide the rest of the team, kind of through that experience of the requirements changes. – P15
Cause Being Aware of Others’ Emotions and Direct consequence Managing Relationships. –Shared by all participants.
All of the participants in our study worked in team contexts. In team contexts, there exists a high chance for individuals to witness others expressing their emotions. Our participants were able to identify the emotions that others in their teams felt when handling the RCs. According to our findings, the main emotion the participants identified in others was anxiety. They were also able to recognise differences in emotions others felt according to their role and the level of seniority. As P15 shared,
“There was a very senior member in the team who was just like very calm and very clear and kind of helped the team navigate that emotional journey.” – P15
The key reasons why it is necessary to be aware of others’ emotions in handling RCs, as mentioned by our participants, were (a) understanding the influence of others’ emotions on decision making, (b) fostering better communication, and (c) to empathise better; which collectively helps in managing relationships. Our study participants believed that not understanding others’ emotions properly can lead to wrong decisions. Thus, it is necessary to gauge team members’ feelings to understand and question their decisions, and to understand any individual biases in making decisions. They also mentioned that for better communication it is necessary to know if others are emotion-driven or not, so that they can potentially tailor their approach to working with them. As per our analysis, being aware of others’ emotions helps empathise better. That is, it helps them to identify what triggers different emotions of others and to interact with others in the team with an understanding. It also helps them to better understand how ‘the team is feeling’ and helps them to better perceive the work the team is doing. They can also get an idea if others understand what they are doing, and see if the team shares the same feelings to maintain the project velocity. For example, as P17 mentioned,
“That is something that I’ve recently learned that it is important to know how others are feeling as well. Because at the end of the day, the velocity of the work that we’re doing as a team, not just depends upon you, but it depends upon the rest of the team as well, so unless everybody is like pretty enthusiastic about the work we’re doing, things do not get done. So it’s really important to be aware of how the rest of the team is feeling as well.”–P17
Extended Consequences: Sustaining Productivity. –Shared by P1, P6, P8, P11–P18.
We found the direct consequences of regulating one’s own emotions and managing relationships help in sustaining individual productivity and setting and sustaining team goals. Further, our findings on extended consequences in relation to the existing literature, [21] notes that goal-setting (specifically continuous reflective goal-setting) supports developers with identifying, monitoring, and maintaining good work habits that improve productivity and their well-being.
Our participants said that not being able to regulate their negative emotions impacts their productivity during RC handling. For example, spiraling of emotions (feeding the negative emotions back to themselves to make the situation worse) and the team feeling overwhelmed can harm productivity. They also mentioned that if they felt that they lacked autonomy, did not feel a sense of project ownership, and/or were not able to change this situation, this resulted in lower productivity levels. However, according to our findings, being able to regulate their emotions does not cause a negative impact on their productivity. For example, if they focus on learning from the RC what they could do better next time (S6), this helps prevent their negative emotions from impacting their productivity. They also stated that emotions can lead to improving or reducing productivity, depending on how they are handled. Thus, they consider emotions as a catalyst and use them to improve productivity. As P15 said,
“Sometimes those emotions are good catalysts. I think the nervousness, as I said, kind of catalysing me to take this discussion and kind of have I’ve had this revisit of what we’ve decided previously, like, I think that was like productive because without the emotion without that sort of need to protect the team, I otherwise would have just stuck to the plan and kind of had, you know, inertia carry me forward. So yeah, I think it’s interesting. I think they can be both productive and unproductive, depending on how their channels are handled.” – P15
Extended Consequences: Setting and Sustaining Team Goals. –Shared by P1, P2, P13, P15, P17.
Having better relationships and regulating negative emotions were claimed to help set and sustain team goals. For example, as P13 mentioned, at the beginning of the project, the team gets together and decides the direction of the project, i.e., sets a team goal which they do via open communication. And as P2 said,
“We try to keep emotion out of what we do because emotion is not helpful in situations where you have an end goal to deliver.” – P2
4.6 Interview Findings – Strategies
We identified 12 strategies (summarised in Table 4) that our software practitioners use to support aspects of EI during RC handling. Namely, sharing how individuals feel with manager/peers (one–to–one/many) (S1), open and regular communication (many–to–many) (S2), building personal rapport with others (S3), empathising (S4), being open to RCs (S5), focusing on learning from the RC (S6), pre/ post control of expectations about the RC (S7), understanding/using the level of autonomy an individual has over RC implementation (S8), tracking commitments and decisions (S9), having a dedicated lead for RC (S10), having team/ social rituals (S11), and working as a single cross functional team (S12). These strategies help in being aware of their own emotions (S1, S2), being aware of others’ emotions (S2–S4, S11, S12), regulating own emotions (S1, S2, S5–S8), and managing relationships (S2, S3, S9–S12).
Strategy S1. Sharing How Individuals Feel with Manager/ Peers (one–to–one/many). –Shared by P4, P5, P8, P9, P11–P18.
This strategy not only helps in being aware of one’s own emotions, but also helps in regulating one’s own emotions. As our participants mentioned, they share how they feel with others individually and in their team when necessary by talking, messaging, having regular catch ups with the manager and at weekly, monthly, and quarterly frequencies. For example,
“And then like if that helps you realise and understand yourself a bit more I think having someone you can vent to, or write a message to or talk to about like a difficult situation is, is one of the most useful things, ways I’ve dealt with it.” – P13
However, some participants mentioned that it is difficult for them to share their emotions openly in group settings, especially during agile retrospectives. Some also mentioned that junior members and new members find it difficult to express their emotions in group settings, where they second guess if their emotions are valid. On the other hand, participants mentioned that senior members express confidently how they feel. This shows that sharing emotions openly happens when adapted to the team context or the company culture or confidence that comes with the position (senior) and experience. For instance,
“More senior people on the team I guess feel a little more confident or comfortable in their abilities to share what they are enjoying, whereas juniors may second guess whether their feelings are valid, and so are less inclined to share them openly with the team in something like a retro.” – P15
Some participants also mentioned that in large groups or when their degree of psychological safety is low, team members are unwilling to express their “raw” emotions in front of others in the team. In contrast, they said that small groups better promote the freedom to express these emotions. Therefore, sharing how one feels in one-to-many situations is subjective. However, some participants mentioned that they anonymously share how they feel during agile retrospectives, and retrospectives help reframe emotions to get them out of doom spirals.
Strategy S2. Open and Regular Communication (many–to–many). –Shared by P1, P2, P4–P18.
Open and regular communication strategies serve in many ways. It helps being aware of own emotions, being aware of others’ emotions, regulating own emotions, and managing relationships. This strategy is very much connected to strategy S1. Our participants mentioned that they have quick discussions during a sprint meeting on resource allocation for the RC, discuss the complexity of existing tasks to decide on an RC assignment, discuss team velocity, communicate the mistakes with others in the team, identify risks open to the team very clearly, and question the rationale for RC/last minute RC through open and regular communication. They mentioned that it helps them “voice out” their opinions and feelings, and therefore helps in being aware of own emotions, and regulate their emotions. They also mentioned that open communication with a reduced number of communication layers promotes better communication about RCs, and clarity about the RC. For example,
“Perhaps the problems come in when you have more layers between managers and software developers and the customer and those layers don’t have as much an understanding like it’s going through a marketing department. I did have this happen to me in previous role marketing department accept changes without shipping the timeline and then feed that down. And that’s when you get anger and frustration because that’s when you start going to like, we’re not working together anymore. Perhaps that’s the key phrases. when you’re all working together change doesn’t matter.” – P16
Another such occasion is having weekly one-on-ones with another team’s architect where multiple teams work together on an RC.
“So we had weekly syncs – weekly one-on-ones with their architect.” – P18
And P18 answered the follow-up question “were the one-on-ones effective?”, P18 said,
“Yeah. 100% yeah yeah, definitely. Because they were one of the main stakeholders, I suppose. For the project. So I believe one-on-ones were important.” – P18
Teams also tend to ask questions from the technical lead during the project, and the technical leads/ managers provide input where necessary to the team. The participants mentioned that they use voice conversations for complex issues and for fast feedback. Additionally, they have quick calls on Slack to discuss if the messaging threads are long. They also mentioned that they openly do Q&A sessions to discuss decisions made by management when the team had less autonomy in decision making, and they discuss timeline impacts and timeline shifts. This further enhances relationships among members in the team and with the manager. Open and regular communications also allow members to express how they feel freely, making others in the team aware of how they feel.
Strategy S3. Building Personal Rapport with Others. –Shared by P2, P4–P6, P12, P14, P18.
Building personal rapport with others helps being aware of others’ emotions during RC handling and also better manage relationships. Our participants mentioned that they build personal rapport through talking to identify emotionally driven people, and also they would like to build relationships proactively ahead of the project. As P13 mentioned,
“.proactively building relationships ahead of a project. So knowing that a project is coming up in one or two quarters, starting to build relationships with people now so that when I do have to come to them and say, Hi, I need help with this project. They already know who I am. They already know the kind of stuff that I’m going to need from them.” – P13
Some managers also mentioned that they build personal rapport only where necessary. One non-manager, P18 mentioned that they build personal rapport with necessary people only to a limited degree.
“I think to a certain degree. I don’t think closer, the better. I don’t necessarily believe that. I think it’s important to feel comfortable around your teammates. That way, you know, but it makes communication a little bit easier. Because you don’t have to play around with wires to try to not offend anyone or anything like that. And it also just makes, I think it makes you a little bit more empathetic towards why they might say a certain thing. They might feel strongly about a sudden decision. I think that’s important. But being too close with them might mean yeah, sometimes you might not want to say something outright. You don’t want to hurt the feelings.” – P18
Strategy S4. Empathising. –Shared by P3–P5, P8, P10–P16.
Empathising leads to being aware of others’ emotions. Empathising during RC handling divides into three sub categories: empathise (emotion); empathise (cognition); and empathise \(\rightarrow\) take action \(\rightarrow\) help resolve (the next practical step – going beyond empathy towards taking action). According to our findings, all three can be seen in managers, and team members have the first two.
Empathise (emotion): This is where managers empathise with their team members. Managers try to understand/perceive team’s emotions via team leads by asking about the vibe of the team, team members having emotional empathy towards peers, and towards the feature leader. For example, one way that managers empathise is observing the emotion dynamics (change in emotions over time) of their subordinates. They do this via weekly one on one meetings where they dig deep into team members’ emotions. As shared by P8,
“People who are experienced, actually worked, coaching, working one-on-one and just being empathetic to the people in the team.” – P8
Empathise (cognition): This is understanding the rationale for an emotion. For example, understanding why the team members feel negative emotions, understanding/perceiving why a feature lead (dedicated lead of the RC) is getting anxious due to release date shifts, a team’s disappointment on priority shift due to RC, understanding/perceiving some members in the team having negative emotions opposite to their own, understanding/perceiving when members who are not familiar with the RC are a little fatigued, and especially managers understanding team members’ positions in life and work. P4 mentioned,
“You know, I’m quite open with my, like last week I was just filthy grumpy and I openly said to my team, I said look, I’m just seriously grumpy. It’s when I was starting to get sick, and I was like I’m seriously grumpy, I’m actually just going to go home. And they were like rest, enjoy, just have the afternoon off, you know, because they knew that was what was best for me” – P4
Empathise \(\rightarrow\) take action \(\rightarrow\) help resolve: According to our findings, this is seen in managers. Managers help others understand emotions/avoid channelling emotions to decisions, take necessary actions to minimise their negative emotion arousal, and listen and validate why they have concerns. For example, managers console team members who are feeling down, help others to move towards the goal rather than thinking about negative emotions such as frustration, they talk with team members about their emotions and how to navigate them, weigh cost over benefits to determine the decision to project the team’s feelings, let subordinates express their concerns without them feeling the need to justify the concern, and put in contact with people who can help subordinates with solving the issue they have, or, if possible, step in to resolve the issue with regard to the RC. For example,
“Trying to learn people’s patterns and drivers so that we can give those opportunities as early, and you know, this particular engineer, nine times out of 10, if we just leave him alone for a couple of hours he solves his problem. And so that’s his modus operandi, he’s like argh, and then he just goes away, thinks, and then he solves his problem. And we’re like that’s awesome, because we know that and we can support him, you know, hashtag united, and say here’s what we can do to support.” – P4
An instance where P14 helped subordinates using S4,
“There were a couple of people who were subordinates myself. And so the technique that I use to start with is to hear them and let them express what their feeling and let them express whatever their concerns are without either of them feeling the need to justify that concern, or without feeling the need to jump into solving that concern just at first to allow them to express and from my side to support and rationalise and help them feel heard. And then from that starting point, to then work with them either on reassuring them that we can deal with whatever the root of the concern is, taking ownership myself of the problem so that they don’t feel like they’re the sole person dealing with an issue. Or putting them in contact with people who can help them like looking at how you resolve the records. And then more broadly, helping them change the situation that they’re in. So that the root cause either is no longer a reason for concern or so that the baseline reason that the root cause is causing stress and that stress is fringed. But most of it starts with just trying to validate and listen to the person and why they have the concern.” – P14
Strategy S5. Being Open to RCs. –Shared by P1, P2, P4–P10, P13, P16, P18.
According to our findings, one of the key strategies for managing one’s own emotions is being more open to RCs. Understanding RCs as a natural phenomenon in agile software development contexts and considering them a normal practice help the practitioners be open to RCs, and thereby better manage any negative emotions that could arise due to new RCs.
“When we look when we discover edge cases, like I feel like it’s, as I said, it’s sort of normal practice for us, like we expect to discover these things. So there’s nothing really jarring about it.” – P14
.“I don’t react like this. Because, the more I understand requirement change, it doesn’t mean that everything will be blown off. It’s like there are some tricks and turns.” – P9
Our participants also mentioned that RCs could be discovered during development, due to technical reasons, edge cases, or even when assumptions are wrong. However, understanding that there is always a reason for the emergence of an RC, and that handling new RCs is for the best of the product, also helps being open to RCs.
”Knowing that there is a reason even if you don’t know what it is, there is a reason. I guess it is sort of assuming best intent that you know, a customer wants their software they haven’t just done this on a whim.” – P16
“...I don’t feel like I have really had negative experiences with requirements changes. And I think that’s true to the fact that every time they come through. You understand. Like, it comes with a reason why. And if you understand the reason why I think we pretty much usually it’s fine.” –P13
Strategy S6. Focusing on Learning from the RC. –Shared by P1–P5, P9, P13.
Our participants said that focusing on learnings from their RCs allowed them to manage their emotions during RC handling. For example, RCs could have emerged due to failures/mistakes. In such occasions, considering the failures/mistakes as lessons, and understanding the benefits of doing so, have helped our participants to manage their emotions. As P13 said,
“Understand that with every setback, there is a learning and the learning is really what you work with.” – P13
RCs also could lead to them learning new information, and our participants said that they use the new learnings to steer the decisions, which is an additional benefit. One way of steering the decisions through learnings, as mentioned by P15, is by having quick learnings through experiments and change quickly.
“...because I think requirements changes no matter what company you’re at. They are quite common, but in a company like <company name> that does really embrace agile and so does like to experiment, learn quickly, change quickly.”– P15
Strategy S7. Pre/Post Control of Expectations about the RC. –Shared by P1, P2, P4, P6, P7, P9, P14, P16, P18.
According to our findings, practitioners may curate their expectations proactively to avoid low pleasurable emotions. They put in effort to avoid the problem causing low pleasurable emotions by removing the unknowns, and reframe expectations to get past the low pleasurable emotions. For example,
“It’s not like oh my god, I’ve got to change, I’ve set these expectations. We are very good at treating releases as fluid, you know, when they change it’s like we just sort of have this perception, it’s not like we change it because we just can’t be bothered doing something.” – P4
“I think when I first started out, it would freak me out, and I’d think, oh what could, how did I not see this, but you can’t, you can’t plot everything.” – P7
Strategy S8. Understanding/Using the Level of Autonomy an Individual has over RC Implementation. –Shared by P2, P3, P7, P10, P12, P14, P15, P18.
Understanding/using the level of autonomy an individual has over RC implementation can assist practitioners manage their emotions. Our participants described several aspects related to autonomy, which help them manage their emotions when handling RCs: having autonomy to align with the reason for RC, learning that autonomy can affect change and help deal with RCs, understanding the impossibility of controlling the situation/changing decisions about RC as an individual in certain occasions, and making situations better when there is less autonomy. In addition, the entire team learning the boundaries where they can affect change, i.e., understanding the level of autonomy they have, also aids in managing emotions during RC handling. For example,
“I think autonomy like this part of autonomy is actually important. Because when you understand why, and you’re actually aligned with the reason why you’re more likely to to not care about the fact that this thing has changed. You’re just going to try and solve it.” – P13
“We give our developers a lot of breathing space in like autonomy where the requirements are areas a piece of work that needs to be achieved. If you spot something over here that can be improved and everything, they just create a sub task to achieve it. Yeah, we’re not quite as strict with our developers in that space.” – P10
Strategy S9. Tracking Commitments and Decisions. –Shared by P4, P8, P10, P14, P17.
Tracking commitments and decisions throughout the process of RC handling aids in managing team relationships. This is also supported by the use of appropriate tools. For example, our participants mentioned that they use Jira tickets to track commitments, and document/record decisions using Confluence when asynchronous communication within the team exists, hence it helps in managing the relationships within the team. As P10 said,
“We use confluence for a lot of our changes for that space, depending on the size of the change if it’s sort of budget effecting, that’s what it really, it’s documented quite heavily. But for like changes in my team, it’s more the change is just documented as a comment in here” – P10
And P14 emphasised that tracking commitments helps in avoiding unknowns and misunderstandings,
And then, using requests and decision artefacts, so tickets to track commitments and documents to track decisions and through that process, then it’s much easier to avoid unknowns and misunderstandings.” – P14
Strategy S10. Having a Dedicated Lead for RC. –Shared by P13, P16–P18.
Having a dedicated lead for a new RC helps to achieve better relationships within the team. According to our findings, having a dedicated lead who is accountable, responsible, and trustworthy helps them have better relationships within the team, as they are the one who sets proper communication within the team and also helps to successfully implement and deliver the RC. For example, as P13 said,
“We have what we call feature lead within the team. And essentially, is someone who prays down the stories, runs their solution, runs this mission sessions and make sure that the feature is on track in terms of timeline, and all that kind of stuff. So the visually does all that. I didn’t do any of that. So I rely on the feature lead to tell me when they needed me, okay to provide input.” – P13
“So I was the feature lead. Oh, we had other engineers. Yes. We had other engineers on the team to help out. Yeah, but essentially, I had to sort of suss out the requirements. I had to write Jira tickets, plan. What issues we wanted to target each week. ... So, essentially we have these grooming sessions every week where we put tickets into the wall. And so I had to decide which ones were ready. Which ones so had dependencies today and so and so.” – P18
Strategy S11. Having Team/Social Rituals. –Shared by P2, P4, P6, P16.
Having team/social rituals is another strategy used by our participants to be aware of others’ emotions and maintain better relationships among team members. Some of the rituals our participants mentioned that they have include: having a project pre-mortem to discuss what to expect; having one-on-one coffee sessions within the team; having daily sessions to go through code within the team; and maintaining communication ‘touchstones’ within the team. This strategy allows the team to bond, hence know how others feel, and thereby have better communication and relationships. P16’s experience with project pre-mortems as they shared,
“We also as a team like whole series, we have a series of rituals. One quick one that a colleague has brought on is things like Project pre-mortem. Okay. Yeah. So instead of a post-mortem, which, like you’ve finished your project, back over a pre-mortem is when you try and do that at the start of a project. And you’re good to go. Okay, what to go wonderfully, what could go terribly. And everyone’s involved in that. So everyone’s got a really good idea of what the lay of the land is. So when a change comes, it’s never really a big surprise, or it’s, everyone was part of the process. So no one feels like, Oh, you shouldn’t have got this because there’s plenty of opportunity for everyone to have contributed.” – P16
Another example where P2 shared about sharing both failures and successes,
“So, we celebrate our successes as well as our failures. When we’re delivering a project then it’s put up on our leader board for the next month to show the projects that have been delivered. And we, that completed project is added to the project of the developers involved on our intranet.” – P2
Strategy S12. Working as a Single Cross–Functional Team. –Shared by P1, P2, P4, P6–P12, P14, P16.
Working as a single cross–functional team helps team members to be aware of others’ emotions and manage relationships. Working on an RC is not a single function task. Various teams may be involved from receiving the RC, to developing and testing, to delivering the RC. One important fact our participants shared with us is that it is necessary to work as a single cross-functional team, especially when it comes to large organisations. For example, managers of the teams involved in the RC communicate with each other and receive/ take the responsibility on the RC, build the sense of community across the people who are working on the product together, and treat teams of all disciplines as a single cross–functional team, so that other teams are not considered as external contributors. This allows one to know how others in a cross-disciplinary team feel, and also to have better understanding and relationships with them.
“What we’ve done is rather than treating the separate disciplines as external contributors, we treat all of the disciplines as cross–functional single team, okay. And, like I said, build that sense of community across the people who are working on the product together. And in doing that we control for the feeling of the other. And then their change. There’s more of an understanding that there’s a human on the other side of the change, who was also trying to do the best thing they’re trying to do. So vice versa, the engineers have more of an understanding of who the product of the design team are, and why they might be doing the things they’re doing. And similarly, the design of the product team, have more of an empathy for the engineers who are saying we can’t do that it’s not possible and the perfect design that you put together that would look really great.” – P13
In some cases, the teams may be distributed around the globe, but would work together as a single cross-functional team. For instance,
“You know, some new information come up. And they may be intellectually curious and want to understand why. So, I work with four teams in Chennai in India, last time and some in London, and I observe that quite frequently. And they were happy, they were more than comfortable, because it was always a conversation, it was done. It wasn’t, they work tougher as a team. Now, if a new story come in and then of course they would, they may hear about it, but that was just going onto the backlog, so they were comfortable with that as well.” – P8
4.7 Interview Findings – Covariances
Covariance occurs when one variable changes with the changes of the other. In our case, the variables are causes, conditions, consequences, strategies. For example, for different causes (cause is a variable), there are different strategies (strategy is the other variable that changes with the cause). We found three covariances in our study, (A) strategies vary with the causes, (B) strategies vary with the direct consequences, and (C) Ease/ difficulty in executing strategies vary with intervening conditions. We have summarised these covariances in Table 4.
Covariance A. Strategies vary with causes. The strategies used to be aware of own emotions and to be aware of others’ emotions co-vary. However, they also share a common strategy (S2).
Covariance B. Strategies vary with direct consequences. Similar to covariance A, the strategies used to regulate one’s own emotions and to manage relationships co-vary. Common strategies (S2, S4, S9–S12) exist for both direct consequences.
Covariance C. Ease/difficulty in executing strategies vary with intervening conditions. Unlike covariance A and B, covariance C consists of a dimension, i.e., the ease/difficulty in executing the strategies with intervening conditions, which is the mode of work. This covariance applies to the strategies S2, S4, and S9.
5 Survey Study
For development teams and researchers to make the most use of our findings, we decided to conduct a survey study to verify the relationships that emerged from the interview study and explore if any new relationships exist between strategies and causes, and strategies consequences. Therefore, in the survey study we focused on answering the following key research questions:
RQ1. Do practitioners experience the strategies, causes, and consequences we identified in the interview study? – The number of participants in our interview study were only 18. We wanted to explore in a broader sense to see if practitioners experience the strategies, causes, and consequences we found in the interview study.
RQ2. What are the correlations between strategies and causes, and strategies and consequences? – We were specifically interested in applying our findings in practical software development contexts. Therefore, we decided only to focus on the correlations between strategies and causes, and strategies and consequences, rather than focusing on all relationships identified in the interview study. However, for practical use it is necessary to verify the correlations found, and also explore if there are any other relationships existing between strategies and causes, and strategies and consequences.
5.1 Survey Study Approach
Figure 5 shows our survey approach. Given our motivation from the interview based study, we developed the survey questionnaire by having multiple close-ended questions and an open-ended question, recruited participants via Prolific, and collected data on Qualtrics and analysed the data. The entire approach is explained in detail below.
Fig. 5.
5.1.1 [Step 2.1] Survey Questionnaire Development.
Key questions. The survey study’s objective was to gather further evidence to support the findings presented in Table 4 and also to find the existence of any other relationships that we did not find from the interview study. Therefore, we converted the causes, consequences, and strategies to closed-ended question statements. For ease of reading, from this point onwards, we call the causes, consequences, and strategies “experience factors”.
When converting the experience factors to statements, we took three actions as given in Table 5. First, to gain a better understanding of the experience factors, we decomposed some of the experience factors into granular level factors. Second, we replicated the factor of individual productivity to team productivity to capture more about productivity at the team level. Third, we arranged the factors to maintain the questionnaire flow by having factors at the individual level first and the team level next. Altogether, we had close-ended questions representing 22 experience factors.
These close-ended questions let participants rate their agreement with what they experienced in their current/ most recent project. The Likert scale ranged from 1 to 5 (1 = strongly disagree, 5 = strongly agree).
Other questions. We also had questions in place to understand the context of where participants’ experiences were coming from. This included their demographics, team and project information, and the RC type related to the scenario they used to answer the experience factor questions. Apart from these, we included an open-ended question for the participants to share any of their experiences/thoughts relevant to the focus of our study, and two attention-check questions. We included the two attention-check questions in the middle and closer to the end of the questionnaire. The attention-check questions we added were:
—
Respond with the choice next to “strongly agree” to this item
—
Select the second choice for this item
It is important to note that we added these attention-check questions after recruiting the first batch of participants (n = 10). This is explained in the next section.
Finally, the arrangement of the survey questionnaire appeared as context questions \(\rightarrow\) experience factor questions with attention-check questions \(\rightarrow\) one open-ended question. The survey questionnaire was hosted on Qualtrics. The PDF export of the questionnaire can be found in the replication package.
5.1.2 [Step 2.2] Participant Recruitment and Data Collection.
106 participants participated in our study. We used Prolific to recruit participants. The reason why we chose a participant recruitment platform is that in our previous studies, we experienced difficulties in attracting participants by other means, such as by posting on social media and using personal connections in the industry. Given that all survey participants were selected to be working industry practitioners, we wanted to pay them for their time taken, rather than expect them to ‘donate’ their time. We also had a positive experience with Prolific in some previous study ([22]); hence, we decided to choose Prolific instead of any other existing platforms. We spent 6 Sterling Pounds per participant.
We recruited the participants batch-wise. We have used the same approach in other similar studies ([18, 19]) to optimise our quality-checking process by giving close attention to all responses. This ensured receiving responses with better quality. First, we recruited 10 participants. At this point, we did not have any attention-check questions. We noticed that the participants spent a very small amount of time (for example, 1-2 minutes) providing the answers. We rejected such responses and re-recruited participants to replace the rejected responses. Then, we included the attention-check questions and recruited the next batch of participants. In this batch, we accepted responses based on the answers to the attention-check questions and re-recruited the participants who provided wrong answers. The exact process was repeated until we recruited participants within our budget limits. Finally, 106 responses were collected on Qualtrics and exported to CSV for data analysis. The participants took 10-12 minutes on average to answer the questions.
5.1.3 [Step 2.3] Survey Data Analysis.
The quantitative data collected were analysed using Python. We used the package scipy.stats for correlation analysis.
Descriptive statistical analysis. Descriptive statistical analysis was used to analyse context questions, answer RQ1, and also to visually inspect the distribution of answers to the experience factor questions (to aid answering RQ2).
Correlation analysis. To answer RQ2, we decided to conduct a correlation analysis. The insights we were specifically interested in were the direction (whether the relationship is positive or negative) and the strength of the relationships between pairs of two variables (strategies and causes, and strategies and consequences). Therefore, we decided to use a correlation analysis statistical test. To choose the appropriate statistical test for correlation analysis, the next step was to decide whether the test is going to be a parametric or non-parametric test. Parametric tests are suitable when the variables have normally distributed data. After plotting the data for each variable (experience factor), we observed that the data were not normally distributed. Hence, we were left with the option to choose a non-parametric test for correlation of ordinal data. Therefore, we chose Spearman’s rank correlation coefficient test. The Spearman’s coefficient (rs) can range from -1 to +1 for monotonic relationships between two variables. A negative relationship is an rs value between -1 and 0 meaning that when one variable increases, the other variable decreases. A positive relationship is an rs value between 0 and +1 meaning that when one variable increases, the other variable increases. An rs value of 0 means there is no correlation between the two variables. We also found the significance of the correlations using significant threshold \(\alpha\) set to 0.05. As several tests were executed on the same set of data, we did the p-value adjustment by applying Bonferroni correction.
In this section, we present the context of our participants, participants’ experience with experience factors, correlation test results, and verification of relationships found in the interview study and additional relationships we found.
5.2 Survey Findings – Context
Participant Demographics. 106 participants participated in our survey study. The majority of our participants were from Europe (n = 57; 50.94%). Unlike the interview study, the majority of the survey study participants played a single role in their projects (n = 71; 33.02%). Out of them, 35 were developers. The survey participants had a mean total experience of 7.23 years (min-total-experience = 0.1 years; max-total-experience = 35 years), and a mean agile experience of 4.88 years (min-agile-experience = no experience; max-total-experience = 19 years). One participant mentioned that they had 35 years of agile experience, which we considered as a mistake when entering as agile was not introduced 35 years ago. A summary of participant demographics are given in Table 1.
Participants’ Project and Team Information. The majority of the survey participants (n = 104; 96.23%) used agile methods in their most recent/current project they used as the basis for filling the survey questionnaire. There were three participants who used the Waterfall method, and one participant who did not use any specific software development method. All participants worked in teams with an average of 12 members. Further project and team information of the survey participants are given in Table 2.
Participants’ RCs. The participants shared the type of RC they handled and used it as the basis for answering the survey questions as given in Figure 6. The majority of participants handled additions and modifications (34.91%) in their projects, followed by modifications, and together additions, modifications, and deletions (19.81% each). Deletions were the least handled type (0.94%).
Fig. 6.
5.3 Survey Findings – Participants’ Agreement to Individual and Team Experiences – Answer to Step 2.RQ1
Figure 7 shows the participants’ agreement to individual and team experiences while handling RCs during their current/ most recent project.
Fig. 7.
Individual experience factors. The majority of participants agreed (responded either as 4 or 5) that they experienced all the individual experience factors during RC handling, except for sharing how they felt with managers one-to-one. For the statement “I shared how I felt with my manager (one-to-one)”, the majority of participants disagreed (responded as 2; 27.36%). This raises the question, what restricts the practitioners from not sharing how they feel with their manager? The possible answers to this question are given in Section 4.
Team experience factors. Similar to individual factors, for all team factors, the participants agreed (responded either as 4 or 5) that they experienced them except for having team/social rituals. An equal amount of responses (also the highest; 29.25%) were found for responses 3 and 4, where 3 is neutral, and 4 is agree.
5.4 Survey Findings – Correlation Test Results – Answer to Step 2.RQ2
Figure 8 shows the correlation test results between strategies and causes, and strategies and consequences. The visualisation of strong correlations between them is given in Figure 9 and the visualisation of relationships between all of them are given in Figure 10–12 in the Appendix B.
Fig. 8.
Fig. 9.
Significance of the correlations. While the majority of correlations were found as statistically significant ( \(\lt\) 0.05), some correlations were found as not statistically significant. The correlations that are not statistically significant are:
—
S9 and C2;
—
\([\) S1a, S1b, S3-S6, S12 \(]\) and Con1;
—
\([\) S1a-S1c, S11, S12 \(]\) and Con2;
—
\([\) S1-S4, S11, S12 \(]\) and Con3a; and
—
S1c and Con4.
The significance of the correlation between 8/14 strategies and Con3a (sustaining individual productivity) are not statistically significant. Similarly, the correlation between half of the strategies and Con1 (regulating own emotions) are not statistically significant. In contrast, the correlation between:
—
all strategies and C1 (being aware of own emotions);
—
the correlation between all strategies except S9 (tracking commitments and decisions) and C2 (being aware of others emotions); and
—
correlation between all strategies except S1c (sharing how individuals feel in group settings (one-to-many)) and Con4 (setting and sustaining team goals)
are statistically significant.
Strength of the correlations. According to our statistical test results, all correlations showed positive correlations that are either weak (rs \(\lt =\) 0.29), or moderate (0.29 \(\lt\) rs \(\lt =\) 0.49), or strong (rs \(\gt\) 0.49). The weak correlations are not significant as well (Figure 8). From the correlation test results, the strong correlations identified are S3 and C2 (rs = 0.5104), S9 and Con1 (rs = 0.5101), [S4 (rs = 0.4977), S9 (rs = 0.5834), S10 (rs = 0.5062), S11 (rs = 0.4939)] and Con3b, and [S4 (rs = 0.5241), S6 (rs = 0.5232), S7 (rs = 0.4960), S9 (rs = 0.5917), S10 (rs = 0.4932), S11 (rs = 0.5761)] and Con4. All with p-values \(\lt\) 0.0001 which are less than our \(\alpha\) value of 0.05.
Among these, the highest number of strong correlations found between strategies and causes, and strategies and consequences are between strategies and Con4 (setting and sustaining team goals; 6 strong correlations), and between strategies and Con3b (sustaining team productivity; 4 strong correlations).
Verification of relationships found in interview study and additional relationships we found in the survey study. Conducting interviews helped us find the experience factors, informed the survey study, and revealed some of the relationships between experience factors. Through our survey study, we were able to identify more correlations between experience factors, and verify the existence of correlations found in the interview study. As shown in Table 7, many weak, moderate, and strong correlations were found in the survey study. We also found that some relationships that were found in the interview study were not significant according to our statistical analysis ([S1a, S1b, S5, S6] and Con1; [S11, S12] and Con2).
6 Discussion
6.1 Key Findings
Strong correlations: The majority are between strategies and setting and sustaining team goals, followed by strategies and sustaining team productivity. Setting and sustaining team goals, and sustaining “individual” productivity were found as extended consequences in the interview study. However, due to our further analysis in the survey study, we were able to identify that strong positive correlations exist between empathising with others, focusing on learning from the RC, controlling expectations about RC, tracking commitments and decisions as a team, having a dedicated lead for RC, having team/social rituals and setting and sustaining team goals; empathising with others, tracking commitments and decisions as a team, having a dedicated lead for RC, having team/social rituals and sustaining “team” productivity. That these are strong positive correlations suggests that an increase in the use of the above-mentioned strategies may help to: (1) increase the ability of setting and sustaining team goals; and (2) sustain team productivity.
Empathising with others, tracking commitments and team decision making: These have strong correlations between managing emotions, between sustaining team productivity, and between setting and sustaining team goals. This indicates that a use of a single strategy may help in experiencing not only one factor but also multiple factors – regulating own emotions, sustaining team productivity, and setting and sustaining team goals. Empathising is a skill that needs to be fostered internally for individuals. However, tracking commitments and decisions as a team can be done more easily with the use of tracking tools, hence, making it easier to support the EI of the team members.
Strategies and regulating own emotions, and strategies and sustaining individual productivity: Unlike other causes and consequences, only a limited number of significant correlations were found between these factors. Further, multiple weak correlations exist between strategies and sustaining individual productivity. This is an important indication of the necessity for exploring more strategies that help practitioners regulate their own emotions, and sustain their individual productivity. There may be other factors influencing these that need further study, e.g., team size, domain, project maturity and the like.
Correlations between EI aspects and strategies are limited: Even though we found strategies for the four aspects of EI (awareness of own emotions, awareness of others’ emotions, regulating own emotions, and managing relationships), the survey analysis indicated strong correlations between the four aspects and strategies are limited. For example, in Table 6, the strong correlations found were only for C2. being aware of own emotions, and Con1. Regulating own emotions. No strong correlations were found for C1 and Con2 which are being aware of others’ emotions and managing relationships, respectively. Further research using a high volume of data can be done to investigate the existence of missing relationships.
6.2 Implications for Practice and Research
Below we discuss some key implications of our findings for practitioners, including recommendations, and implications for researchers with corresponding ideas for future work.
Recommendation 1. Embrace RCs. RCs are unavoidable in software contexts and, according to our findings, resisting RCs does not help. In contrast, embracing them helps in improving EI when handling RCs. Consequently, this helps in improving the product delivery and developer satisfaction as well. This aligns with our previous study findings about emotions and RCs [18].
Recommendation 2. Ensue effective teamwork practices. As shown in Table 4, open and regular communication is the only strategy that can assist in achieving all four aspects of EI. Therefore, it is highly beneficial if software practitioners and team leads focus on the practice open and regular communication during RC handling. However, a number of factors can hinder such communication, e.g., team distribution, developer personalities, team size, poor leadership and so on. Several of our strategies identified in Section 4.6 can be utilised to assist this. Indeed, half of the strategies that we found (S1–S4, S11, S12) can be said to be inter–personal strategies. Therefore, in order to improve EI for RC change handling, it is necessary not only from an individual perspective, but also to be a better team player and improve overall team climate.
Recommendation 3. Junior members and new members: don’t be afraid to share what you feel with others when handling RCs. Our interview findings show that junior members and new members tend not to share how they feel with others, and second guess the emotions they feel. While sharing emotions in group settings depends on whether the person feels comfortable, sharing how one feels with others helps in improving EI when handling RCs. This also highly relies on the psychological safety within the team. This also requires good team leadership and team climate development.
Recommendation 4. Use appropriate tools and their features to execute strategies according to the mode of work. Our interview study findings indicate that execution of strategies is impacted by the mode of work. Software teams can think how to avoid the mode of work (remote/ in–person) being an intervening condition. For example, P13 mentioned that they use the “huddle” feature in Slack to have quick calls instead of instant messaging when the discussions are long. Such features might be used in remote working settings to enhance open and regular communication.
Recommendation 5. Use the problem–solution chart we have presented: Strategies to use during RC handling to support emotional intelligence. In Table 6, the strategies we have listed can be used during RC handling to help team members raise awareness of their own emotions, to regulate their own emotions, to sustain team productivity, and to set up and maintain team goals. This table can be used as a problem–solution guide. For example, to be aware of others’ emotions, one can consider using the strategies, sharing how individuals feel with manager/ peers (S1), or open and regular communication (S2).
Recommendation 6. Deploying the theoretical framework. Figure 4 outlines our theoretical framework for improving EI during RC handling. This framework can be used to get a better understanding about the central phenomenon of emotional intelligence of software practitioners during RC handling. Other researchers may consider using this theoretical framework via follow-on studies, potentially with differing contexts and conditions, to explore these impacts.
Recommendation 7. Investigating strategies used by practitioners in other parts of the world. The 18 interviews we conducted saturated what we found, and the findings are limited predominantly to the Australasian region, possibly exhibiting territorial, organisational and cultural specificities. Researchers may replicate our study in other regions of the world to see if the practitioners use the same strategies, or whether they use different strategies. Researchers can then expand our theoretical framework to bring more understanding and knowledge on the central phenomenon to include other parts of the world as well.
Recommendation 8. Enhancing the theoretical framework. Our theoretical framework was based on findings from the work experiences shared by our participants. Using different participants from differing contexts, conditions and investigating other software engineering tasks may identify new strategies, consequences and covariances. For example, we only found how mode of work intervenes in executing some of the strategies we found, i.e., how the mode of work intervenes S2, S4, and S9. A future study might consider if the mode of work intervenes in the execution of other strategies as well.
Recommendation 9. Investigating the applicability of strategies in situations beyond RC handling. The strategies we found are limited to RC handling, and they may or may not be applicable for situations beyond RC handling. Researchers may consider studying this further by conducting a study such as a survey to know if the strategies we have listed can be used in other scenarios as well, e.g., design, evaluation, pair programming and so on.
Recommendation 10. Investigating strategy utilisation along with EI maturity within team members. S4 –empathising with others – was commonly found in managers. In reality, the professionals at the management level are the ones with years of experience. Therefore, it can be assumed that managers might have mastered empathising over time. A future study can be conducted to see how strategies such as empathy are utilised across different EI maturity levels within team members.
7 Evaluation and Limitations
Evaluation. We evaluate our STGT method application against credibility and rigour, and our outcome against originality, relevance, and density, as per the STGT evaluation guidelines [10]. Credibility: We have provided details on how participants were recruited (social media, personal contacts, and from a large software company), the applied sampling method (convenience sampling and theoretical sampling), how iterative and interleaved data collection and analysis occurred, and the memos written (textual: interview reflections, conceptual memos; visual: Miro board). Rigour: We have provided an example of open coding, and constant comparison, embedded sanitised evidence (quotes). Originality: To the best of our knowledge, this is the first study on EI in handling RCs (confirmed through related work). Relevance: Our previous studies ([18, 19]) prove how relevant the central phenomenon is for RC handling contexts. Density: The findings are layered and full of real examples (quotes).
Limitations. In our interview study, we collected data from 18 software practitioners engaged in requirements change handling in software engineering. While this is a relatively small number of participants, each interview was between 30–60 minutes long, sharing detailed accounts and experiences on the relevant issues. Qualitative analysis of these interviews provided rich insights into the various components of EI as it applies to requirements change handling, as is evident from the multi-faceted nature of the theoretical framework. When working in a team, coding by a single researcher can lead to a potentially restricted view of the data. To address this, the first author analysed all data and shared the findings with the second and third authors. During weekly meetings, the second author went through the codes of the first iteration to confirm the reliability. In the second set of interviews the first author wrote extensive memos of interview reflections and conceptual memos, visualised findings using Miro, and shared with both the second and third authors during the process. We also had fortnightly discussions on findings.
In this paper, we used a mixed-methods approach, i.e., a combination of a pre-interview questionnaire, interviews, and a survey. Each of these methods have their own advantages and disadvantages, but using them all together for the study helped us uncover rich insights. For example, if not for the pre-interview questionnaire, the time to focus on the topic during the interview could have been limited. Hence, using a pre-interview questionnaire to cover participants’ demographics and some context information was beneficial. An interview study by itself may not be useful if it is necessary to verify findings in a broader sense as well. In that case, an approach such as a survey with multiple participants would be useful – hence, we followed. If we conducted only a survey study, then it will have limitations such as not being able to have follow-up questions or to elicit adequate responses from the participants. Therefore, using interviews to capture the data in-depth and using the survey to verify the findings was useful. Another point in our study is how we lined up the methods to meet our objective. First, we started with an interview study to gain deep understanding of the topic, and then focused on verifying the findings through a survey study. The crafting of the research method was done solely to align with the objective of the study. Therefore, this might not be applicable to other studies with different objectives. For example, if one needs to have a high level understanding of a topic first and explore it in-depth later, then having interviews later rather than having them earlier would match the situation better. However, for studies like ours, the approach we have taken can be useful.
The first set of interviews was conducted before the Covid-19 pandemic, the second set of interviews was conducted during the pandemic, and the survey was conducted post-pandemic. Therefore, the participants’ modes of work varied in each study, however, overall, the majority of the participants worked remotely. The findings could have been different if the majority of the participants worked in person. For example, as we have mentioned under recommendation 1, open and regular communication might be hindered due to team distribution (remote workers distributed at different geographical locations).
Overall we found nearly all of our practitioners quite open to discussing their emotional reactions (good and bad) during our interviews. A couple of practitioners in our first round of interviews had a little reluctance to discuss their negative emotions. This could be a potential threat to validity of Findings. One might find the interview questions we had were uncommon to the software practitioners who participated in our study. The participants participated in the study knowing its nature. Therefore, it was seen that they were ready to answer the types of questions we had. We also used an approach in the interviews where they started talking about a situation they handled requirements changes and getting deeper into discussion in the interview. We believe that it did not bring any discomfort to the participants, rather it helped them reveal how they felt.
We used Prolific to recruit participants in the survey study. This included a payment to the participants. Since the focal point of our study was related to emotions and also as we paid the participants for their participation, it could be seen that their participation might not be completely honest. This is common in survey studies. However, participation in our study was anonymous, and we believe that it prevented the above-mentioned point to some extent.
8 Conclusion
We set out to study the role of emotional intelligence during requirements change handling in software engineering. Through an empirical study, we identified the six Cs of software practitioners’ emotional intelligence during requirements change handling, including the context, conditions, causes, consequences, and strategies. We found that there exist covariances among causes, consequences, and strategies, and mode of work intervenes the execution of the strategies we identified. These are inclusive of, but also go beyond, the four known aspects of emotional intelligence – self-awareness (being aware of own emotions), social awareness (being aware of others’ emotions), self regulation (regulating own emotions), and relationship management (managing relationships) [8]. Empathising with others and tracking commitments and decisions as a team are key strategies that have strong correlations between managing emotions, between sustaining team productivity, and between setting and sustaining team goals. Based on our findings, we present a set of recommendations for software practitioners, and a set of potential future work for researchers.
Acknowledgments
Our sincere gratitude goes to the large software company who gave us the opportunity to recruit participants, and to everyone at the company who helped with reviewing the pre-interview questionnaire, recruiting participants, reading the draft and providing valuable feedback, and to all the participants who took part in this study.
Footnotes
1
The University of Auckland Human Research Ethics Approval Number: 02315, Monash University Human Research Ethics Approval Number: 23578.
2
Monash University Human Research Ethics Approval Number: 37904.
A Findings Coverage by Participants
Table 8.
Fig. 10.
B Counts of Participant Responses
Fig. 11.
Fig. 12.
References
[1]
Danyllo Albuquerque, Everton Guimaraes, Mirko Perkusich, Alexandre Costa, Emanuel Dantas, Felipe Ramos, and Hyggo Almeida. 2020. Defining agile requirements change management: A mapping study. In Proceedings of the ACM Symposium on Applied Computing. Association for Computing Machinery, 1421–1424. DOI:
[2]
Zornitza Bakalova, Maya Daneva, Andrea Herrmann, and Roel Wieringa. 2011. Agile requirements prioritization: What happens in practice and what is described in literature. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 6606 LNCS (2011), 181–195. DOI:
[3]
Nomi Baruah. 2015. Requirement management in agile software environment. In Procedia Computer Science, Vol. 62. Elsevier B.V., 81–83. DOI:
[4]
K. Beck, M. Beedle, A. Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas. 2001. Manifesto for Agile Software Development. (2001).
[5]
Elizabeth Bjarnason, Krzysztof Wnuk, and Björn Regnell. 2011. A case study on benefits and side-effects of agile practices in large-scale requirements engineering. In Proceedings of the 1st Agile Requirements Engineering Workshop, AREW’11 - In Conjunction with ECOOP’11. DOI:
[6]
Francisco Gomes De Oliveira Neto, Jennifer Horkoff, Eric Knauss, Rashidah Kasauli, and Grischa Liebel. 2017. Challenges of aligning requirements engineering and system testing in large-scale agile: A multiple case study. Proceedings - 2017 IEEE 25th International Requirements Engineering Conference Workshops, REW 2017 (92017), 315–322. DOI:
[7]
Barney G. Glaser. 1978. Theoretical Sensitivity: Advances in the Methodology of Grounded Theory. University of California.
[8]
Daniel Goleman, Richard Boyatzis, and Annie McKee. 2002. The emotional reality of teams. Journal of Organizational Excellence 21, 2 (2002). DOI:
[9]
James J. Gross and Ross A. Thompson. 2007. Emotion regulation: Conceptual foundations. In Handbook of Emotion Regulation. J. J. Gross (Ed.), Handbook of Emotion Regulation. New York: Guilford Press. Vol. 3.
[10]
Rashina Hoda. 2021. Socio-technical grounded theory for software engineering. IEEE Transactions on Software Engineering (82021), 1–1. DOI:
[11]
Irum Inayat, Siti Salwah Salim, Sabrina Marczak, Maya Daneva, and Shahaboddin Shamshirband. 2015. A systematic literature review on agile requirements engineering practices and challenges. Computers in Human Behavior 51 (102015), 915–929. DOI:
[12]
Liu Jun, Wang Qiuzhen, and Gao Lin. 2010. Application of agile requirement engineering in modest-sized information systems development. In Proceedings - 2010 2nd WRI World Congress on Software Engineering, WCSE 2010, Vol. 2. 207–210. DOI:
[13]
Marja Käpyaho and Marjo Kauppinen. 2015. Agile requirements engineering with prototyping: A case study. 2015 IEEE 23rd International Requirements Engineering Conference, RE 2015 - Proceedings (112015), 334–343. DOI:
[14]
Sander Koole. 2009. The Psychology of Emotion Regulation: An Integrative Review. (2009), 4–41 pages. DOI:
[15]
Makrina Viola Kosti, Robert Feldt, and Lefteris Angelis. 2014. Personality, emotional intelligence and work preferences in software engineering: An empirical study. Information and Software Technology 56, 8 (2014). DOI:
[16]
Peter Koval, Emily A. Butler, Tom Hollenstein, Dianna Lanteigne, and Peter Kuppens. 2015. Emotion regulation and the temporal dynamics of emotions: Effects of cognitive reappraisal and expressive suppression on emotional inertia. Cognition and Emotion 29, 5 (72015), 831–851. DOI:
[17]
Kashumi Madampe, Rashina Hoda, and John Grundy. 2021. A faceted taxonomy of requirements changes in agile contexts. IEEE Transactions on Software Engineering (2021). DOI:
[18]
Kashumi Madampe, Rashina Hoda, and John Grundy. 2022. The emotional roller coaster of responding to requirements changes in software engineering. IEEE Transactions on Software Engineering (2022). DOI:
[19]
Kashumi Madampe, Rashina Hoda, and John Grundy. 2023. A framework for emotion-oriented requirements change handling in agile software engineering. IEEE Transactions on Software Engineering (2023), 1–20. DOI:
[20]
Kashumi Madampe, Rashina Hoda, and Paramvir Singh. 2020. Towards understanding emotional response to requirements changes in agile teams. In IEEE/ACM 42nd International Conference on Software Engineering New Ideas and Emerging Results (ICSE-NIER’20). ACM, New York, NY, USA, Seoul, Republic of Korea, 4.
[21]
Andre N. Meyer, Gail C. Murphy, Thomas Zimmermann, and Thomas Fritz. 2021. Enabling good work habits in software developers through reflective goal-setting. IEEE Transactions on Software Engineering 47, 9 (92021), 1872–1885. DOI:
[22]
Humphrey O. Obie, Hung Du, Kashumi Madampe, Mojtaba Shahin, Idowu Ilekura, John Grundy, Li Li, Jon Whittle, Burak Turhan, and Hourieh Khalajzadeh. 2022. Automated detection, categorisation and developers’ experience with the violations of honesty in mobile apps. (112022). DOI:
[23]
Balasubramaniam Ramesh, Lan Cao, and Richard Baskerville. 2010. Agile requirements engineering practices and challenges: An empirical study. Information Systems Journal 20, 5 (92010), 449–480. DOI:
[24]
Azadeh Rezvani and Pouria Khosravi. 2019. Emotional intelligence: The key to mitigating stress and fostering trust among software developers working on information system projects. International Journal of Information Management 48 (2019). DOI:
[25]
Klaus R. Scherer. 1987. Toward a dynamic theory of emotion. Geneva Studies in Emotion (1987).
[26]
Anselm Strauss and Juliet Corbin. 1998. Basics of Qualitative Research Techniques.
[27]
Gary R. VandenBos. 2007. APA Dictionary of Psychology. American Psychological Association.
[28]
Stefan Wagner, Daniel Méndez Fernández, Marcos Kalinowski, and Michael Felderer. 2018. Agile requirements engineering in practice: Status quo and critical problems. CLEI Electronic Journal 21, 1 (2018), 6–1.
Index Terms
- Supporting Emotional Intelligence, Productivity and Team Goals while Handling Software Requirements Changes
Recommendations
The Affect of Software Developers: Common Misconceptions and Measurements
CHASE '15: Proceedings of the 2015 IEEE/ACM 8th International Workshop on Cooperative and Human Aspects of Software EngineeringThe study of affects (i.e., emotions, moods) in the workplace has received a lot of attention in the last 15 years. Despite the fact that software development has been shown to be intellectual, creative, and driven by cognitive activities, and that ...
Understanding the affect of developers: theoretical background and guidelines for psychoempirical software engineering
SSE 2015: Proceedings of the 7th International Workshop on Social Software EngineeringAffects--emotions and moods--have an impact on cognitive processing activities and the working performance of individuals. It has been established that software development tasks are undertaken through cognitive processing activities. Therefore, we ...
The Relationship between Emotional Intelligence of a Leader and Employee Motivation to Job Performance
This quantitative study investigated the bond between a leader's emotional intelligence to employee motivation. The research was conducted at a federal government agency resided north bound of the United States of America. Participants consisted of 350 ...
Comments
Please enable JavaScript to view thecomments powered by Disqus.Information & Contributors
Information
Published In
July 2024
951 pages
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected].
Publisher
Association for Computing Machinery
New York, NY, United States
Publication History
Published: 27 June 2024
Online AM: 11 May 2024
Accepted: 10 April 2024
Revised: 26 February 2024
Received: 24 April 2023
Published in TOSEM Volume 33, Issue 6
Check for updates
Author Tags
Qualifiers
- Research-article
Funding Sources
- ARC Laureate Fellowship
Contributors
Other Metrics
Bibliometrics & Citations
Bibliometrics
Article Metrics
- 0Total Citations
- 380Total Downloads
- Downloads (Last 12 months)380
- Downloads (Last 6 weeks)289
Reflects downloads up to 14 Aug 2024
Other Metrics
Citations
View Options
Get Access
Login options
Check if you have access through your login credentials or your institution to get full access on this article.
Sign in