Software development is a collaborative task involving diverse development teams, where toxic communication can negatively impact team mood and project success. Mood surveys enable the early detection of underlying tensions or dissatisfaction within development teams, allowing communication issues to be addressed before they escalate, fostering a positive and productive work environment. The mood can be surveyed indirectly by analyzing the text-based communication of the team. However, emotional subjectivity leads to varying sentiment interpretations across team members; a statement perceived neutrally by one developer might be seen as problematic by another developer with a different conversational culture. Early identification of perception volatility can help prevent misunderstandings and enhance team morale while safeguarding the project.

As software systems grow increasingly complex, explainability has become a crucial non-functional requirement for transparency, user trust, and regulatory compliance. Eliciting explainability requirements is challenging, as different methods capture varying levels of detail and structure. This study examines the efficiency and effectiveness of three commonly used elicitation methods—focus groups, interviews, and online surveys—while also assessing the role of taxonomy usage in structuring and improving the elicitation process. We conducted a case study at a large German IT consulting company, utilizing a web-based personnel management software. A total of two focus groups, 18 interviews, and an online survey with 188 participants were analyzed. The results show that interviews were the most efficient, capturing the highest number of distinct needs per participant per time spent. Surveys collected the most explanation needs overall but had high redundancy. Delayed taxonomy introduction resulted in a greater number and diversity of needs, suggesting that a two-phase approach is beneficial. Based on our findings, we recommend a hybrid approach combining surveys and interviews to balance efficiency and coverage. Future research should explore how automation can support elicitation and how taxonomies can be better integrated into different methods.

Software development is a collaborative task involving different persons. Development team members are often diverse in regard to several aspects, including experience, (soft) skills, and communication habits. Different preferences in what adequate communication looks like influence how communication is perceived and interpreted by team members. In this paper, we investigate differences and similarities in how software developers with varying levels of experience and skills perceive statements from exemplary software project communication. By applying hierarchical cluster analysis on the perception data of 94 software developers, we aim to find groups of developers sharing similar perceptions towards statements from software project communication, and to identify factors that influence this perception. We contribute the following key findings: (1) We statistically identify two groups of software developers whose perceptions differ significantly for about 65% of statements from software project communication; (2) For a logistic regression model, five polarizing statements suffice to assign each participant to their group; (3) Although there is a significant difference in the communication perception, there are no demographic characteristics that differ notably across the two groups. From our results, we conclude that different perceptions of software project communication during collaboration within development teams are a potential risk for the teams’ mood and the project success. We outline how our results can serve use cases like the application of sentiment analysis in software engineering and mindful communication in software teams in general.

With the integration of generative artificial intelligence (GenAI) tools such as GitHub Copilot into development processes, developers can be supported when writing code. As GitHub Copilot has a feature to provide up to ten solutions at once, we explore, how developers should approach those solutions with the goal of providing recommendations to achieve suitable trade-offs in finding correct solutions and checking solutions. In this study, we analyze a total of 2025 coding problems provided by LeetCode and 17 048 solutions to solve these problems generated by GitHub Copilot in Python. We focus on three key issues: firstly, whether it is beneficial to consider multiple solutions; secondly, the impact of the position of a solution; and thirdly, the number of solutions that should be checked by a developer. Overall, our results point to the following observations: (1) solutions are not less likely to be correct if they appear at later positions; (2) when looking for a solution to a common problem, checking four to five solutions is generally enough; (3) novel or difficult problems are unlikely to be solved by GitHub Copilot; (4) skipping the first solution is advised when considering only one solution, as the first solution is less likely to be correct; and (5) checking all solutions is necessary to not miss correct solutions, but the effort is usually not justified. Based on our study, we conclude that there is potential for improvement in better supporting developers. For instance, there are few cases where ten generated solutions provide more value than fewer solutions. Depending on the use scenario, it could be more useful if GitHub Copilot allowed developers to request a single, comprehensive solution.

Ensuring traceability of safety- and security-related artifacts is vital in software development to comply with standards and mitigate risks. Despite its importance, the practical implementation of defining and tracing safety- and security-relevant artifacts remains ambiguous. Based on eight semi-structured interviews with industry experts, this work explores the definitions, methods, processes, and challenges of tracing safety- and security-related artifacts. The interviews revealed that definitions of safety- and security-relevant artifacts are highly context-dependent, shaped by regulatory standards, internal processes, technical characteristics, and practitioner judgment. Rather than signaling a deficiency, this variability reflects the inherently multifaceted nature of safety and security work, where artifact classification emerges from practical reasoning rather than strict or universal criteria. Tools play a key role in supporting traceability, and cross-team alignment remains a concern in practice. Our findings provide actionable insights for organizations seeking to strengthen traceability. The recommendations encourage the development of internal classification criteria, support effective collaboration with external partners, support guidance, onboarding, and training, and help align practices with across teams, fostering more reliable and transparent management of safety- and security-relevant artifacts.

With the rise of artificial intelligence in industry, many companies rely on machine learning methods such as time series forecasting. By processing data from the past, such systems can provide predictions for data in the future. In practice, however, there is often skepticism about the quality of the forecasts. Explainability has been identified as a means to address this skepticism and foster trust. While there are already different methods to explain time series forecasts, it is unclear which of these explanations are actually useful for stakeholders. To investigate the need for explanations for time series forecasts, we conducted a study at a mid-sized German company in the energy domain. Throughout the study, 23 participants were shown five examples of different explanation types. For each type of explanation, we tested if it actually helped our participants to better understand the forecasts. We found that visual explanations including decision trees and feature importance charts were able to improve domain experts' understanding of time series forecasts. Textual explanations tended to lead to confusion rather than empowerment. While the exact findings and preferable types of explanations may vary between companies, our concrete results can provide a starting point for in-depth analyses in other environments.

Abstract Demonstrating software early and responding to feedback is crucial in agile development. However, it is difficult for stakeholders who are not on‐site customers but end users, marketing people, or designers, and so forth to give feedback in an agile development environment. Successful graphical user interface (GUI) test executions can be documented and then demonstrated for feedback. In our new concept, GUI tests from behavior‐driven development (BDD) are recorded, augmented, and demonstrated as videos. A GUI test is divided into several GUI unit tests, which are specified in Gherkin, a semi‐structured natural language. For each GUI unit test, a video is generated during test execution. Test steps specified in Gherkin are traced and highlighted in the video. Stakeholders review these generated videos and provide feedback, for example, on misunderstandings of requirements or on inconsistencies. To evaluate the impact of videos in identifying inconsistencies, we asked 22 participants to identify inconsistencies between (1) given requirements in regular sentences and (2) demonstrated behaviors from videos with Gherkin specifications or from Gherkin specifications alone. Our results show that participants tend to identify more inconsistencies from demonstrated behaviors, which are not in accordance with given requirements. They tend to recognize inconsistencies more easily through videos than through Gherkin specifications alone. The types of inconsistency are threefold: The mentioned feature can be incorrectly implemented, not implemented, or an unspecified new feature. We use a fictitious example showing how this feedback helps a product owner and her team manage requirements. We conclude that GUI test videos can help stakeholders give feedback more effectively. By obtaining early feedback, inconsistencies can be resolved, thus contributing to higher stakeholder satisfaction.

[Background.] Empirical research in requirements engineering (RE) is a constantly evolving topic, with a growing number of publications. Several papers address this topic using literature reviews to provide a snapshot of its “current” state and evolution. However, these papers have never built on or updated earlier ones, resulting in overlap and redundancy. The underlying problem is the unavailability of data from earlier works. Researchers need technical infrastructures to conduct sustainable literature reviews. [Aims.] We examine the use of the Open Research Knowledge Graph (ORKG) as such an infrastructure to build and publish an initial Knowledge Graph of Empirical research in RE (KG-EmpiRE) whose data is openly available. Our long-term goal is to continuously maintain KG-EmpiRE with the research community to synthesize a comprehensive, up-to-date, and long-term available overview of the state and evolution of empirical research in RE. [Method.] We conduct a literature review using the ORKG to build and publish KG-EmpiRE which we evaluate against competency questions derived from a published vision of empirical research in software (requirements) engineering for 2020–2025. [Results.] From 570 papers of the IEEE International Requirements Engineering Conference (2000–2022), we extract and analyze data on the reported empirical research and answer 16 out of 77 competency questions. These answers show a positive development towards the vision, but also the need for future improvements. [Conclusions.] The ORKG is a ready-to-use and advanced infrastructure to organize data from literature reviews as knowledge graphs. The resulting knowledge graphs make the data openly available and maintainable by research communities, enabling sustainable literature reviews.

With the emergence of agile software development methods, new approaches for determining agile maturity have become necessary. Other than for traditional maturity and capability models like CMMI and ISO/IEC 15504, the field of agile maturity models is not yet settled. Even worse, a common understanding regarding agility in general and the levels of agility in particular is missing. The paper at hand aims to shed light on the field of agile maturity models with a particular focus on maturity levels, their definition, and their evaluation and computation. We conducted a systematic literature review to extract maturity levels and provide an initial harmonization of the levels found. Our findings from analyzing 19 agile maturity models show that there is yet no agreement with regard to the maturity levels. In total, 69 maturity levels have been analyzed for harmonization opportunities. Two major dimensions of maturity levels of agile maturity models could be identified: (1) team-related and (2) general maturity, which is comparable to standard approaches. However, the procedures to assess organizations and processes, if at all present, are to a large extent focused on persons and their personal opinion, which paves the way for future research, e.g., in terms of developing measurement systems for assessing agile maturity.

In software projects, stakeholders can give valuable feedback on software demonstrations. Demonstrating software early and responding to feedback is crucial in agile development. However, it is difficult for stakeholders who are not on-site customers but end users, marketing people, or designers, etc. to give feedback in an agile development environment. Successful Graphical User Interface (GUI) tests, which show the working GUI with expected software behaviors, can be documented and then demonstrated for feedback. In our new concept, GUI tests are recorded, extended, and demonstrated as videos. A GUI test is divided into several GUI unit tests, which are specified in Gherkin, a semi-structured natural language. For each GUI unit test, a video is generated during test execution. Test steps specified in Gherkin are traced and highlighted in the video. Stakeholders review these generated videos and provide feedback, e.g., on misunderstandings of requirements or on inconsistencies. To evaluate the impact of videos in identifying inconsistencies, we asked 22 participants to identify inconsistencies between (1) given requirements in regular sentences and (2) demonstrated behaviors from videos with Gherkin specifications or from Gherkin specifications alone. Our results show that participants tend to identify more inconsistencies from demonstrated behaviors which are not in accordance with given requirements. They tend to recognize inconsistencies more easily through videos than through Gherkin specifications alone. We conclude that GUI test videos can help stakeholders give feedback more effectively. By obtaining early feedback, inconsistencies can be resolved, thus contributing to higher stakeholder satisfaction.

[Background:] Teamwork, coordination, and communication are a prerequisite for the timely completion of a software project. Meetings as a facilitator for coordination and communication are an established medium for information exchange. Analyses of meetings in software projects have shown that certain interactions in these meetings, such as proactive statements followed by supportive ones, influence the mood and motivation of a team, which in turn affects its productivity. So far, however, research has focused only on certain interactions at a detailed level, requiring a complex and fine-grained analysis of a meeting itself. [Aim:] In this paper, we investigate meetings from a more abstract perspective, focusing on the polarity of the statements, i.e., whether they appear to be positive, negative, or neutral. [Method:] We analyze the relationship between the polarity of statements in meetings and different social aspects, including conflicts as well as the mood before and after a meeting. [Results:] Our results emerge from 21 student software project meetings and show some interesting insights: (1) Positive mood before a meeting is both related to the amount of positive statements in the beginning, as well as throughout the whole meeting, (2) negative mood before the meeting only influences the amount of negative statements in the first quarter of the meeting, but not the whole meeting, and (3) the amount of positive and negative statements during the meeting has no influence on the mood afterwards. [Conclusions:] We conclude that the behaviour in meetings might rather influence short-term emotional states (feelings) than long-term emotional states (mood), which are more important for the project.

Abstract Since the publication of the agile manifesto in 2001, many companies implement an agile—or at least more agile—software development process. However, only including agile methods or practices in the overall process does not guarantee being agile. The mindset of the people involved in the process, including the development team, the customers, and the management, is of particular importance. As such an agile mindset cannot be enforced, the process of creating a suitable mindset needs to be handled with care. In an interview study with nine agile coaches, we analyzed which aspects they perceive being of particular importance during an agile transformation. One of these aspects is the agile mindset. We figure out how they support the creation of such a mindset. We identify 12 categories related to the process of creating an agile mindset. These categories include the collaboration between the coach and the management as well as the necessity to internalize the agile values. The main factor for succeeding with the creation of an agile mindset, however, can be hardly influenced: The success strongly depends on the personal prerequisites and attitudes of the individuals involved in the process, mainly the development team. We synthesize the results of our study into a timeline describing the process of how an agile coach can support the development team creating an agile mindset as part of the transformation towards an agile development process.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Software development is a collaborative task and, hence, involves different persons. Research has shown the relevance of social aspects in the development team for a successful and satisfying project closure. Especially the mood of a team has been proven to be of particular importance. Thus, project managers or project leaders want to be aware of situations in which negative mood is present to allow for interventions. So-called sentiment analysis tools offer a way to determine the mood based on text-based communication. In this paper, we present the results of a systematic literature review of sentiment analysis tools developed for or applied in the context of software engineering. Our results summarize insights from 80 papers with respect to (1) the application domain, (2) the purpose, (3) the used data sets, (4) the approaches for developing sentiment analysis tools and (5) the difficulties researchers face when applying sentiment analysis in the context of software projects. According to our results, sentiment analysis is frequently applied to open-source software projects, and most tools are based on support-vector machines. Despite the frequent use of sentiment analysis in software engineering, there are open issues, e.g., regarding the identification of irony or sarcasm, pointing to future research directions.

Software engineers in modern development settings often face the challenge of contributing to large existing projects. The comprehension of foreign software code presents a time consuming obstacle, especially in contexts like onboarding. New employees have little knowledge of the software project they are supposed to contribute to. Therefore, tools supporting developers with their code comprehension are desirable to help them contribute to the best of their ability as soon as possible. Such tools must be flexible enough to work with any software project, while offering means for adjustments to very specific tasks.In this paper, we present an approach to visualize source code as node-link diagrams, using expert-designed ontologies to group various source code elements such as classes or methods. We evaluate our approach with nine advanced computer science students simulating an onboarding in a software project consisting of almost 100k lines of code. The results show that our approach supports code comprehension by utilizing expert knowledge of the visualized project, while also pointing to other use cases such as legacy code migration.

Abstract Hardly any software development process is used as prescribed by authors or standards. Regardless of company size or industry sector, a majority of project teams and companies use hybrid development methods (short: hybrid methods) that combine different development methods and practices. Even though such hybrid methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this article, we make a first step towards a statistical construction procedure for hybrid methods. Grounded in 1467 data points from a large‐scale practitioner survey, we study the question: What are hybrid methods made of and how can they be systematically constructed? Our findings show that only eight methods and few practices build the core of modern software development. Using an 85% agreement level in the participants' selections, we provide examples illustrating how hybrid methods can be characterized by the practices they are made of. Furthermore, using this characterization, we develop an initial construction procedure, which allows for defining a method frame and enriching it incrementally to devise a hybrid method using ranked sets of practice.

Abstract Product Owners have an important role in the agile and hybrid software development process. While this role is supposed to maximize the value of a product, there seem to be several scattered results on how they achieve this, as well as what actually constitutes this role in practice. To consolidate current research results and to further analyze the key attribute of Product Owners, we conducted a multi‐method research approach spanning a systematic mapping study and a consecutive case study in a hybrid development environment. The results of the mapping study states that Product Owners are communicators. We further investigated on this and used the shadowing technique to observe three Product Owners' communication activities. The results support that statement, as the gained data reveal that Product Owners spend 65% of their time in meetings. But rather than just providing the team with the necessary requirements for the product under development, Product Owners need this time to synchronize and align their work, streamline the agile process of large‐scale Scrum, discuss team‐based topics, and to solve upcoming issues addressed by the team. These results contribute to draw a more comprehensive picture of the important but yet complex role of Product Owners in practice.

Fast feedback promotes agile teams to improve their work during the software process, making it crucial for team success. Information systems accelerate the availability of information that result in compact knowledge sources. In practice, feedback in Sprints is often limited to sole progress and performance measures, e.g., burndown charts or velocity diagrams. Sprint insights related to team dynamics are rarely considered, even though they frequently cause project failures, e.g., lack of social interaction. In this paper, we describe a survey study conducted with international members of the software engineering community to reveal which information helps agile teams the most and provides practical support in Sprints. We describe results in an experience report highlighting the frequent information problems and needs of agile teams, considering the perspective of 90 researchers and practitioners. The responses were quantitatively interpreted. The report promotes understanding about how or what kind of information would be useful for agile development teams. Moreover, it reveals what information problems were perceived as crucial for project success and avoidable, considering proper team feedback. The study endorses practical needs for system-aided feedback that supplies knowledge on the human factors in Sprints. The findings are relevant for practitioners and researchers that struggle on improving team feedback based on information needs.

Selecting a suitable development method for a specific project context is one of the most challenging activities in process design. Every project is unique and, thus, many context factors have to be considered. Recent research took some initial steps towards statistically constructing hybrid development methods, yet, paid little attention to the peculiarities of context factors influencing method and practice selection. In this paper, we utilize exploratory factor analysis and logistic regression analysis to learn such context factors and to identify methods that are correlated with these factors. Our analysis is based on 829 data points from the HELENA dataset. We provide five base clusters of methods consisting of up to 10 methods that lay the foundation for devising hybrid development methods. The analysis of the five clusters using trained models reveals only a few context factors, e.g., project/product size and target application domain, that seem to significantly influence the selection of methods. An extended descriptive analysis of these practices in the context of the identified method clusters also suggests a consolidation of the relevant practice sets used in specific project contexts.

Agile software development teams strive for fast and continuous feedback. Both the quality of the resulting software and the performance of the team require feedback. The performance of the team developments is often addressed in retrospectives which are not only part of the SCRUM framework, but also in general. Reflecting on incidents during the last sprint helps the team to increase performances, expressed by, e.g., efficiency and productivity. However, it is not only essential to identify volatile sprint performances, but also to characterize the primary cause to solve them. Main reasons for low performance are often not visible, primarily when they are related to social-driven team behavior, such as communication structures, mood, or satisfaction. In this paper, we analyze whether automated team feedback about retrospective sprint-behavior can help the team to increase performances due to additional awareness about the dynamic effects over time. In a comparative case study with 15 software projects and a total of 130 undergraduate students, we investigated the sustainable impact of feedback on human aspects. Our results indicate that automated feedback positively affects team performances - and customer satisfaction.

Among the multitude of software development processes available, hardly any is used by the book. Regardless of company size or industry sector, a majority of project teams and companies use customized processes that combine different development methods--so-called hybrid development methods. Even though such hybrid development methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this paper, we make a first step towards devising such guidelines. Grounded in 1,467 data points from a large-scale online survey among practitioners, we study the current state of practice in process use to answer the question: What are hybrid development methods made of? Our findings reveal that only eight methods and few practices build the core of modern software development. This small set allows for statistically constructing hybrid development methods. Using an 85% agreement level in the participants' selections, we provide two examples illustrating how hybrid development methods are characterized by the practices they are made of. Our evidence-based analysis approach lays the foundation for devising hybrid development methods.

Product Owners in the Scrum framework - respectively the On-site Customer when applying eXtreme Programming - have an important role in the development process. The Scrum Guide states that this role is responsible for the requirements and maximizing the value of the product. However, the implementation of this role depends on the individual, the organization and the team and is perceived as difficult in industry. Various research approaches provide insights in the applied PO role in industry - yet, a conclusive bigger picture of the studies and reports on this issue is missing. To fill this gap, we conducted a systematic mapping study. Our findings structure the research area of Product Owners in industry in terms of research topics and applied research methods. In total, we identified 30 contributions addressing seven research topics and generated consolidated answers for each of them. While some of those topics provide congruent results, others point to gaps in current research: So is the PO role in large-scale projects clearly defined as a group effort, but questions regarding the leadership and management responsibilities of POs remain unanswered. Also, the impact of external circumstances on the PO role is a question that is worth to answer in future work.

In agile software development, the sprint performances and dynamics of teams often imply tendencies for the success of a project.Post mortem strategies, e.g., retrospectives help the team to report and share individually gained experiences (positives and negatives) from previous sprints, and enable them to use these experiences for future sprint planning.The interpretation of effects on sprint performance is often subjective, especially with concern to social-driven factors in teams.Involving strategies from predictive analytics in sprint retrospectives could reduce potential interpretation gaps of dynamics, and enhance the pre-knowledge, also awareness situation when preparing for the next sprint.In a case study involving 15 software projects with a total of 130 involved undergraduate students, we investigated the post-effects on team performances and behavioral-driven factors when providing predictive analytics in retrospectives.Besides measures for productivity, we consider human factors, e.g., team structures, communication, meetings and mood affects in teams as well as project success metrics.We developed a unique JIRA plugin called ProDynamics that collects performance information from projects and derives trend-insights for next sprints.The ProDynamics plugin enables the use of a times series and neural network model within a JIRA system to interpret factorial dependencies and behavioral pattern, thus to show the next sprint course of a team.

Abstract Almost all companies struggle with software systems that are getting increasingly complex. Therefore, in particular large companies often use software product lines, which provide an efficient way to manage software reuse as well as the high complexity. However, software product lines seem to be too slow to react to changes. Agile development approaches promise to meet this demand. At the same time, integrating an agile approach is not always easy. Consequently, there is a need for a transformation model that supports the agile transformation without harming the benefits of software product lines. In this paper, we present the results of a literature review regarding agile transformation in large software companies. Our results summarize the insights from 85 papers and present a list of 20 tasks and tasks that are recommended by several researchers to be considered during the transformation. On the basis of these results, we create an agile transformation model—the so‐called “agile hamburger”—that contains these tasks and preserves software product lines. Since the model is rather coarse grained and generic, we also support the adaption to different teams by presenting an assessment model tailored to the demands of the automotive domain.

Software process improvement has always been an essential part of software projects. Current market trends and the rapid pace of changing requirements demand fast development and adaptability. Agile software development is a popular possibility to react on these trends. Implementing agile practices promises for example a shorter time-to-market, satisfied customers and increased software quality. Consequently many companies strive for an integration of agile methods or for an agile transformation.

Information sharing in teams is one of the most important aspects of successful software development. For instance, requirements, design decisions and guidelines need to be communicated with the whole team or with specific team members. For information exchange, communication is mandatory. Meetings are an effective way to communicate with many team members. Hence, much information can be shared during team meetings. But meeting and communication behavior may vary. During the project, the team members get to know the others more and more. This has an influence on the chosen ways of information sharing and hence changes communication behavior.We are interested in analyzing the influence of meetings on team-internal communication and collaboration. To analyze collaboration, we consider a measure of indirections representing used communication channels and the perceived communication intensity between each of the team members. In a study with 65 students across eight development teams, we examine how intensively team members used various communication channels and if there is a change in communication and meeting behavior over time.In our study, the communication behavior becomes increasingly effective during the development process and the number of team meetings decreases in the course of the project. Moreover, the teams decentralize their communication behavior during project progress. According to our results, there is no cause for concern if there are less or shorter meetings at the end than at the beginning of a project.

Estimating dynamic components in projects involves understanding human factors which are substantial in software development.Communication and collaboration in teams consist of social-driven characteristics with influences on the continuous delivery of software.Efficiently estimated meetings become increasingly important due to budget calculations and shortened release cycles.Experiences of project managers combined with retrospectives on historical data records support a better understanding of team dynamics.But interpreting complex effects is not always trivial, in particular without further analyzes.In several studies, information relationships are investigated through linear correlation measures.Additional analyses for higher correlations are often neglected due to the advanced functional characterization.This leads to statistical gaps with significances for explored data relationships and their functional interpretation.In this paper, we present a systematic identification and visualization of team communication effects and diversities for field study records of 34 student software projects.We combine methodologies from system dynamics with exploratory data analysis to extract and emphasize significant effects.These insights help to sensitize for advanced investigations about the statistical measures of correlation and to interpret sophisticated structures.Furthermore, it reinforces potentials for a team's communication performances and enables an enhanced understanding about how student teams meet and communicate.