Supporting Emotional Intelligence, Productivity and Team Goals while Handling Software Requirements Changes
Abstract
1 Introduction
2 Background and Motivation
2.1 Definitions
2.2 Background
2.2.1 Requirements Change Handling.
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 |
2.2.2 Emotional Intelligence.
2.3 Motivating Example
3 Study Design
4 [Step 1] Interview Study
4.1 Interview Study Approach
4.1.1 [Step 1.1] Interview Protocol Development.
4.1.2 [Step 1.2] Transitional Piloting.
4.1.3 [Step 1.3A] Data Collection.
4.1.4 [Step 1.3B] Data Analysis.
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 |
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 |
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 |
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 |
4.2 Overview of Interview Study Findings
4.3 Interview Findings – Context
4.4 Interview Findings – Conditions
“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
“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
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
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
“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
“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
“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
“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
“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
“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
“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
“So we had weekly syncs – weekly one-on-ones with their architect.” – P18
“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
“.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
“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
“People who are experienced, actually worked, coaching, working one-on-one and just being empathetic to the people in the team.” – P8
“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
“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
“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
“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
”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
“Understand that with every setback, there is a learning and the learning is really what you work with.” – P13
“...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
“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
“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
“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 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
“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
“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
“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
“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
“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
5 Survey Study
5.1 Survey Study Approach
5.1.1 [Step 2.1] Survey Questionnaire Development.
5.1.2 [Step 2.2] Participant Recruitment and Data Collection.
5.1.3 [Step 2.3] Survey Data Analysis.
5.2 Survey Findings – Context
5.3 Survey Findings – Participants’ Agreement to Individual and Team Experiences – Answer to Step 2.RQ1
5.4 Survey Findings – Correlation Test Results – Answer to Step 2.RQ2
6 Discussion
6.1 Key Findings
6.2 Implications for Practice and Research
7 Evaluation and Limitations
8 Conclusion
Acknowledgments
Footnotes
A Findings Coverage by Participants
B Counts of Participant Responses
References
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
![cover image ACM Transactions on Software Engineering and Methodology](/cms/asset/9ab6682c-cf0d-44e2-9d1f-fa2e97900704/3613693.cover.jpg)
Publisher
Association for Computing Machinery
New York, NY, United States
Publication History
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
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