Abstract Agile at scale introduces persistent tensions as organizations attempt to balance autonomy, coordination, and control across teams and layers. Some tensions are paradoxes, which are persistent contradictions in which both sides matter. Drawing on a qualitative case study of MarketCorp, a multinational marketplace company, we explore how paradoxes manifest in a large-scale agile context and how leaders respond. Interviews with 15 top managers and reflective conversations with 60 employees reveal three paradoxes: centralization vs. autonomy, internal vs. external focus, and product vs. project approaches. We explored two approaches for designing facilitated dialogue around paradoxes in leadership teams. The study highlights the importance of recognizing, normalizing, and collaboratively managing paradoxes and offers practical guidance for large-scale agile organizations, demonstrating that paradoxes can provide a valuable focus for continuous improvement and strengthen agile learning practices.

Context: Pair programming (PP) is more relevant than ever. As modern systems grow in complexity, knowledge sharing and collaboration across teams have become essential. However, despite well-documented benefits of PP, its adoption remains inconsistent across software teams. Objective: This study aims to understand the factors that facilitate or hinder team members’ adoption as well as lasting engagement in PP. Method: We have conducted an exploratory single-case study in a mature agile company in Norway. We collected data through two rounds of interviews with team members in different roles and performed a thematic analysis of the interviews. Results: Our key finding is that multiple factors, related to the perceptions of how PP contributes to daily work, social dynamics and learning, efforts associated with engaging in PP sessions, company and team attitudes, resources, infrastructure, and task characteristics, affect PP engagement. Conclusion: Long-term engagement in PP requires expected benefits with the practice being confirmed in firsthand experiences. Adapting the practice to each unique team, with insights drawn from collective learning, is also beneficial. Our findings will be beneficial for software practitioners seeking to make PP an integrated part of their team’s workflow.

Onboarding is an important activity to integrate new employees into an organization as soon as possible, in order to support them in becoming productive. Whereas onboarding has traditionally been done primarily onsite, it is now increasingly common for new software professionals to be onboarded either fully remotely or partially remotely in hybrid settings. We ask how software professionals develop a sense of belonging through the onboarding process. Using a conceptual framework from the general onboarding literature, we report on case studies of onboarding of software professionals in three different settings on the hybrid continuum, drawing on a dataset comprising interviews with 46 informants, Slack logs, observations, and company documents. In Case 1, we focus on the onboarding of consultant developers in two divisions: in one division, the consultants work internally with the consulting organization. In the other division, the consultants are placed with clients. In Case 2, we study the onboarding of software professionals in a hybrid setting, and in Case 3, we study the onboarding of a new team of remote developers based in Portugal, who joined a company in Norway. We extend the literature on onboarding of software professionals by shedding light on how software organizations conduct onboarding in different types of hybrid settings. We extend and refine the initial conceptual model, and formalize it through the development of a series of propositions. We then discuss a number of recommendations for software organizations who wish to onboard new software professionals in different settings on the hybrid continuum.

Abstract Context Organizations opt for continuous delivery of incremental updates to deal with uncertainty and minimize waste. However, applying continuous engineering (CSE) practices requires a continuous feedback loop with input from customers and end-users. Challenges It becomes increasingly challenging to apply traditional requirements elicitation and validation techniques with ever-shrinking software delivery cycles. At the same time, frequent deliveries generate an abundance of usage data and telemetry informing engineering teams of end-user behavior. The literature describing how practitioners work with user feedback in CSE, is limited. Objectives We aim to explore the state of practice related to utilization of user feedback in CSE. Specifically, what practices are used, how, and the shortcomings of these practices. Method We conduct a qualitative survey and report analysis from 21 interviews in 13 product development companies. We apply thematic and cross-case analysis to interpret the data. Results Based on our earlier work we suggest a conceptual model of how user feedback is utilized in CSE. We further report the identified challenges with the continuous collection and analysis of user feedback and identify implications for practice. Conclusions Companies use a combination of qualitative and quantitative methods to infer end-user preferences. At the same time, continuous collection, analysis, interpretation, and use of data in decisions are problematic. The challenges pertain to selecting the right metrics and analysis techniques, resource allocation, and difficulties in accessing vaguely defined user groups. Our advice to practitioners in CSE is to ensure sufficient resources and effort for interpretation of the feedback, which can be facilitated by telemetry dashboards.

Context: Teamwork is an important aspect of agile software development, and the widespread adoption of agile methodologies emphasizes the need for educational approaches that prepare students for effective teamwork. Capstone courses in agile software engineering provide a valuable setting for students to experience collaborative work. However, the dynamics within these teams, particularly regarding gender, require further exploration. Objectives: This study examines teamwork experiences in an agile capstone course focusing on how team gender composition affects role distribution, teamwork quality, and gender bias. Methods: This study involved 94 teams comprising 561 students over two years (213 women and 348 men). We employed a mixed-methods approach, using four surveys (806 responses) and 12 in-depth interviews to capture ambition level, satisfaction with agile practices, and gender differences. Results: Team gender composition significantly impacted teamwork quality (TWQ), with female-dominated but gender-diverse teams showing the highest TWQ scores. Interestingly, women in token positions in male-majority teams reported unexpectedly high satisfaction levels, challenging aspects of Kanter’s tokenism theory. However, women were more likely to report that team members underestimated their competence, particularly in male-majority teams. Observed gender differences included a tendency for women to engage more in design and process-oriented tasks, while men predominantly focused on programming and technical aspects such as architecture and algorithms. Conclusion: This study underscores the importance of considering team composition in relation to gender in agile teams, as we found this aspect greatly impacts team dynamics. Further, the implementation of agile practices in capstone courses yielded high overall TWQ scores, indicating significant educational value. Our findings provide insights for both software engineering education and agile practitioners.

ABSTRACT Process debt, like technical debt, can be a source of short‐term benefits but often leads to harmful consequences in the long term for a software organization. Despite its impact, the phenomenon of process debt has not been thoroughly explored in current literature, leaving a gap in understanding how it affects and is managed within organizations. This paper addresses this gap by defining process debt, describing its occurrence, the risks of its mismanagement, and showing examples of mitigation strategies. Our study began with an exploratory phase involving semi‐structured interviews with sixteen practitioners across four international organizations, allowing us to gather diverse insights into the occurrence and management of process debt. Then, to deepen our understanding and validate our findings, we conducted a cross‐company focus group with ten additional practitioners and analyzed fifty‐eight observations and thirty‐five interviews from a longitudinal case study. The analysis of the research findings led to a definition of process debt and a novel framework. We also report on the causes, consequences, and occurrence patterns of process debt over time. We present mitigation strategies and discuss which ones need further attention for future research. Our results suggest that the debt metaphor may help companies understand how to manage and improve their processes and make process‐related decisions that are beneficial both in the short and long term.

Abstract Large-scale agile software development is increasingly being organized with product management. Although product management is familiar to software engineering, we need research-based knowledge about organizing product management in an agile development context. This study focuses on product management challenges and configurations in a Nordic fintech organization with 10,000 employees. We conducted 19 interviews with participants involved in core product management activities. The study identifies ten key factors that hinder product management performance in a large-scale agile product company. Further, we present six product management configurations used in the fintech organization. The most suitable setup depends on the product lifecycle stage, product size, and development team setup. Our summary of the product management configurations and challenges can guide software product managers working in large-scale agile companies.

Abstract Team composition is a critical factor influencing collaboration within agile software development. This study investigates the impact of gender distribution on teamwork quality in software engineering capstone courses. We examined the experiences of 240 students organized into 40 teams during an agile project course. We analyzed two surveys, one conducted before team composition and one at the end of the project work. As much as 91% of the students chose to use the practice of conducting stand-up meetings in their project work and the majority were satisfied with the practice. Further, our analysis reveals that while women tend to engage more in design and men in programming, an increase in the proportion of women within a team correlates with a higher involvement of women in programming tasks. Our findings highlight gender differences in perceptions and experiences related to project involvement in agile software engineering courses.

Abstract This paper examines the role of the enterprise social networking (ESN) tool Slack in the daily work of software practitioners within NAV, a large-scale agile public sector organization. Based on 13 interviews with NAV developers, our case study explores how Slack is employed for knowledge sharing and daily communication across the organization. We used a newly developed framework for communication in agile teams as a theoretical lens. Through our analysis, we found that Slack use had become deeply integrated into the organizational culture and fostered alignment in three main ways: Promotingcommunication transparencythrough open discussions visible for developers organization-wide, enhancingcommunication qualitywith prompt responses and constant communication, and encouragingcommunication disciplinethrough structured channels and threads. This study also unveiled some challenges, such as information overload and hindered focus. However, our findings suggest that if common hurdles are overcome, modern ESN tools can reshape how cross-organizational communication plays out in large-scale agile, reinforcing the agile principles of collaboration and motivated individuals.

Pair programming (PP) has been a widespread practice for decades and is known for facilitating knowledge exchange and improving the quality of software. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artifacts incorporated in the shared workspace when pairing. After a long period of forced work-from-home, many knowledge workers prefer to work remotely two or three days per week, which is affecting practices such as PP. In this revelatory single-case study, we aimed to understand how PP is practiced during hybrid work when team members alternate between on-site days and working from home. We collected qualitative and quantitative data through 11 semi-structured interviews, observations, feedback sessions, and self-reported surveys. The interviewees were members of an agile software development team in a Norwegian fintech company. The results presented in this paper indicate that PP can be practiced through on-site, remote, and mixed sessions, where the mixed mode seems to be the least advantageous. The findings highlight the importance of adapting the work environment to suit individual work mode preferences when it comes to PP. In the future, we will build on these findings to explore PP in other teams and organizations practicing hybrid work.

Abstract Datafication processes, the ongoing strive for making organizations data-driven, have in recent years entailed data-focused software projects and more interdisciplinary teamwork. Simultaneously as agile product teams have been directed towards increased use of data for software development, stronger data protection regulations such as GDPR have further complexified the software developer role, whose responsibilities and expectations now expand far beyond mere coding. Seeking to develop an understanding of how data-intensive product teams in the public sector maneuver the legal hurdles emerging in the wake of data governance, this paper builds on 19 interviews with members of two agile product teams in the Norwegian organizations NAV and Entur. Our findings indicate that including a legal expert in the team can boost confidence in data handling practices and avoid delays in deliveries, but it requires effort to synchronize and overcome interdisciplinary barriers.

Abstract Context Responding to change and continuously improving processes, practices, and products are core to agile software development. It is no different in large-scale agile, where multiple software development teams need to respond both to changes in their external environments and to changes within the organization. Objective With this study, we aim to advance knowledge on coordination in large-scale agile by developing a model of the types of organizational changes that influence coordination mechanisms. Method We conducted a longitudinal case study in a growing large-scale agile organization, focusing on how external and internal changes impact coordination over time. We collected our data through 62 days of fieldwork across one and a half years. We conducted 37 interviews, observed 118 meetings at all organizational levels, collected supplementary material such as chat logs and presentations, and analyzed the data using thematic analysis. Results Our findings demonstrate how external events, such as onboarding new clients, and internal events, such as changes in the team organization, influence coordination mechanisms in the large-scale software development program. We find that external and internal change events lead to the introduction of new coordination mechanisms, or the adjustment of existing ones. Further, we find that continuous scaling requires continuous change and adjustment. Finally, we find that having the right mechanisms in place at the right time strengthens resilience and the ability to cope with change in coordination needs in complex large-scale environments. Conclusions Our findings are summarized in an empirically based model that provides a practical approach to analyzing change, aimed at supporting both researchers and practitioners dealing with change in coordination mechanisms in large-scale agile development contexts.

Software development organizations need testers with high skill levels in a broad range of technical areas and application domains. Accordingly, we need a better understanding of how testers meet such skill demands in the practice of their role. This work aims to deepen the understanding of the typical tester role. We performed a thematic analysis of 19 in-depth, semi-structured interviews with software testers working in various industries. To investigate employers’ views on such roles, we conducted a thematic analysis of 400 job ads. From the interviews, we identified five subroles of software testers: domain-specific tester, test automation specialist, test infrastructure specialist, user experience tester, and test manager. Most of the practitioners preferred to develop skills and act in one subrole. In contrast, most of the job ads requested that testers act in multiple subroles. Our findings provide a deeper understanding of the tester role, which may guide testers in their acquisition of skills and employers in the recruiting of testers.

In large-scale agile software development, many teams work together to achieve overarching project goals. The more teams, the greater the coordination requirements. Despite the growing popularity of large-scale agile, inter-team coordination is challenging to practice and research. We conducted a case study over 1.5 years in a large-scale software development firm to better understand which inter-team coordination mechanisms are used in large-scale agile and how they support inter-team coordination. Based on a thematic analysis of 31 interviews, 113 hours of observations, and supplemental material, we identified 27 inter-team coordination mechanisms. From this, we offer the following contributions. First, we propose a taxonomy of inter-team coordination with three categories: coordination meetings, such as communities of practice, inter-team stand-ups, and retrospectives; coordination roles, such as the program architects and the platform team; and coordination tools and artefacts, such as Slack and JIRA as well as inter-team task boards, product backlogs, and roadmaps. Second, the coordination mechanisms displayed combinations of four key characteristics, technical, organizational, physical, and social (TOPS), which form the basis of the TOPS framework to capture the multifaceted characteristics of coordination mechanisms.Technicalrelates to the software product and/or technical tools supporting software development.Organizationalpertains to the structural aspects of the organization.Physicalrefers to tangible or spatial characteristics.Socialcaptures interpersonal and community-based characteristics. Finally, the taxonomy and the TOPS framework provide a knowledge base and a structured approach for researchers to study as well as for software practitioners to understand and improve inter-team coordination in large-scale agile.

Abstract Although extensive research has been conducted on the characteristics of the agile developer, little attention has been given to the features of the software-testing role. This paper explores the human factors of the software testers working in agile projects through a qualitative study focusing on how these factors are perceived. We interviewed 22 agile software practitioners working in three international companies: 14 testers, five developers, and three designers. Additionally, we observed 11 meetings and daily work of 13 participants in one of the companies. Our findings show that the views on the human factors shaping the agile software tester’s role were crystallized into seven traits, which the agile team members saw as central for the software-testing role: the ability to see the whole picture, good communication skills, detail-orientation, structuredness, creativeness, curiosity, and adaptability. The testers spent half their day communicating and learned how to mitigate the fact that they had to bring bad news to other project members. They also facilitated communication between the business side and development. Based on our results, we propose the seven traits as dimensions to consider for organizations recruiting agile software testers, as well as a reference for IT and non-IT professionals considering a software-testing career.

Abstract Inter-team coordination in large-scale software development can be challenging when relying on agile development methods that emphasize iterative and frequent delivery in autonomous teams. Previous research has introduced the concept of coordination strategies, which refer to a set of coordination mechanisms to manage dependencies. We report on a case study in a large-scale agile development program with 16 development teams. Through interviews, meeting observations, and supplemental document analyses, we explore the challenges to inter-team coordination and how dependencies are managed. We found four coordination strategies: 1) aligning autonomous teams, 2) maintaining overview in the large-scale setting, 3) managing prioritizations, and 4) managing architecture and technical dependencies. This study extends previous research on coordination strategies within teams to the inter-team level. We propose that large-scale organizations can use coordination strategies to understand how they coordinate across teams and manage their unique coordination situation.

Abstract Along with the increasing popularity of agile software development, software work has become much more social than ever. Contemporary software teams rely on a variety of collaborative practices, such as pair programming, the topic of our study. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artefacts incorporated in the shared workspace, which the COVID-19 pandemic made unavailable; most software companies around the world were forced to send their engineers to work from home. As software projects and teams overnight turned into distributed collaborations, we question what happened to the pair programming practice in the work-from-home mode. This paper reports on a longitudinal study of remote pair programming in two companies. We conducted 38 interviews with 30 engineers from Norway, Sweden, and the USA, and used the results of a survey in one of the case companies. Our study is unique as we collected the data longitudinally in April/May 2020, Sep/Oct 2020, and Jan/Feb 2021. We found that pair programming has decreased and some interviewees report not pairing at all for almost a full year. The experiences of those who paired vary from actively co-editing the code by using special tools to more passively co-reading and discussing the code and solutions by sharing the screen. Finally, we found that the interest in and the use of PP over time, since the first months of the forced work from home to early 2021, has admittedly increased, also as a social practice.

Context: There is an indisputable industrial need for highly skilled individuals in the role of software testers. However, little is known about the educational background of these professionals, their first contact with the role, their preferences in acquiring skills, the impediments they face, and their perception of the software testing role. Objective: In the current paper, we report on the background, skills, learning preferences, and role profiles as described by professionals in software testing, spanning over a significant number of industries, countries, and software development models. Method: We conducted 19 in-depth, semi-structured interviews with software testing practitioners, across eight industries. We performed a content and thematic analysis of the collected data. Results: The practitioners in software testing had diverse educational backgrounds, and their first contact with the testing role was accidental. Exploratory testing was the preferred testing technique, while curiosity was identified as the most important feature in their skill set. Our respondents collaborated extensively with the developers, whom they perceived as a learning source and symbiotic work partner. Conclusion: The professionals in software testing described their skills as a rather undefined heap of knowledge, increasing with each work task. They used mainly informal and hands-on learning approaches. They found it necessary for education providers to present information on software testing. Generally, companies assisted them well in their skill development but need to allocate sufficient time for the learning. We identified five specialties of the role: product owner in testing, UX tester, DevOps tester, test-script automator, and test-process coordinator.

Many companies have turned towards globally distributed software development in their quest for access to more development capacity. This paper investigates how a company onboarded distributed teams in a global project, and report experience on how to study such distributed projects. Onboarding is the process of helping new team members adapt to the existing team and ways of working. The goal of the studied onboarding program was to integrate Portuguese developers into two existing Norwegian teams. Further, due to the growing trend in utilizing globally distributed projects, and the challenge of conducting studies in distributed organizations, it is crucial to find good practices for researching such projects. We collected qualitative data from interviews, observations, Slack conversations and documents, and quantitative data on Slack activity. We report experiences on different onboarding practices and techniques, and we suggest guidelines to help other researchers conduct qualitative studies in globally distributed projects.

Although there has been extensive research on software testing technicalities - such as testing tools and practices - little research have been conducted within human factors of software testing. In collaboration with Itera, a consultancy company, we begin to fill this research gap. Our current qualitative data-set consists of observation notes, interview transcripts, and conversation logs. Our findings suggest that creativity, being structured, having the ability to see the whole picture, having good interpersonal skills, and eagerness-to-learn are desired traits for a software tester.

Given the relevance of coordination in the field of global software engineering, this work was carried out to further understand coordination mechanisms. Specifically, we investigated meetings and the collaboration tool Slack. We conducted a longitudinal case study using a mixed-methods approach with surveys, observations, interviews, and chat logs. Our quantitative results show that employees in global projects spend 7 h 45 min per week on average in scheduled meetings and 8 h 54 min in unscheduled meetings. Furthermore, distributed teams were significantly larger than co-located teams, and people working in distributed teams spent somewhat more time in meetings per day. We found that low availability of key people, absence of organizational support for unscheduled meetings and unbalanced activity from team members in meetings and on Slack were barriers for effective coordination across sites. The positive aspects of using collaboration tools in distributed teams were increased team awareness and informal communication and reduced the need for e-mail. Our study emphasizes the importance of reflecting on how global software engineering teams use meetings and collaboration tools to coordinate. We provide practical advice for conducting better meetings and give suggestions for more efficient use of collaboration tools in global projects.

Developing software with high quality is challenging in distributed software development. The purpose of the current study is to investigate the testing skills and tools required in the ever-changing world of global software engineering, according to industrial needs. We analysed 500 job ads from 33 countries. The results show that a quarter of the testers and a fifth of developers are asked to work in distributed projects. The testers are asked to be highly skilled in a variety of test activities and tools, while the testing-skills demand for developers is low and somewhat vague. The profile of testers has a strong technical component in addition to the managerial one. Our findings show that employers need most that testers are competent in automated testing. Furthermore, the industry does not cover all aspects of testing with the demand for testers and developers. Surprisingly, neither role is asked to test the implementation of the general data protection requirements. Our study bridges the industrial needs and the practitioners' skill development process. Therefore, software testers can use our study as a reference point to enhance their skills. Employers should use our results to check their testing-skill coverage within the development teams. Tertiary education providers are encouraged to use our findings, to update the curriculum in the software development area.

Offshore outsourcing of software development has been both famous for the promises of great cost reductions, and infamous for the hidden costs associated with the challenges of organizing software work over distance. Experience shows that many of these costs do not receive the deserved attention and are often excluded when making offshoring decisions. As a result, there is often a significant deviation between the expected and the realized costs of offshoring. In this paper, we investigate the awareness of the extra costs when making an offshoring decision, and the significance of the actual cost deviations. We conducted a single case study of a company that carried out an offshore outsourcing pilot project. We collected qualitative data from interviews, observations and a retrospective, and quantitative data on the costs and effort associated with the project. We conclude that the company was aware of the hidden cost factors, but largely underestimated their significance. The costs that surfaced in the studied project accounted for a total deviation of 181% and several individual cost categories with more than 400% overrun. The two main cost drivers in our study were the distance and poor process fit, which escalated the investments needed to make the collaboration work. Our results suggest that pilots are useful to understand the key problem areas in an offshoring collaboration, but too limited to shed light on all potential problems (e.g. turnover) due to the short timeframe. We also conclude that results of pilot projects shall not be the only data source when calculating the true costs of offshoring, since the start-up phase of an offshoring relationship carries large investments. Finally, we provide recommendations for companies in a similar situation on how to run and learn from offshore outsourcing pilot projects.

Virtual teams rely on enterprise social networking tools such as Slack to collaborate efficiently. While such tools contribute to making the communication more synchronous and support distributed agile development, there are several challenges such as how to interact with each other and how to balance the communication with other types of communication mechanisms such as meetings, e-mail, and phone. In this paper, we describe and discuss how a distributed global project used Slack. Some of the challenges we identified were related to language problems, using too much direct messaging when communicating, and unbalanced activity (33% of the users accounted for 86% of the messages). The positive aspects of using the tool were increased transparency, team awareness, and informal communication. Further, Slack facilitates problem-focused communication which is essential for agile teams. Our study stresses the importance of reflecting on how virtual teams use communication tools, and we suggest that teams decide on guidelines on how to use the tools to improve their coordination.

Abstract In agile software development, a core responsibility of the product owner (PO) is to communicate business needs to the development team. In large-scale agile software development projects, many teams work toward an overall outcome, but they also need to manage interdependencies and coordinate efficiently. In such settings, POs need to coordinate knowledge about project status and goal attainment both within and across the development teams. Previous research has shown that the PO assumes a wide set of roles. Still, our knowledge about how POs coordinate amongst themselves and with their teams in large-scale agile is limited. In this case study, we explore PO coordination in a large-scale development program through the theoretical lens of Relational Coordination Theory. Our findings suggest that (1) coordination varies depending on the context of each PO, (2) a focus on achieving high-quality communication changes coordination over time, and (3) unscheduled coordination enables of high-quality communication.

Abstract There is a growing interest in making software more accessible for everyone, which is emphasized by the numerous suggestions passed into law in many countries. However, many software organizations that use agile methods postpone or neglect accessibility testing. We aimed to understand how accessibility testing can be better integrated into the daily routine of agile projects by conducting a case study in a Norwegian software company. We investigated three accessibility testing tools: automatic checker, simulation glasses, and a dyslexia simulator. We hosted sessions at which agile project members used the tools while thinking out loud, responded to questionnaires, and were interviewed at the end. Additionally, we observed the project members for 18 workdays. Our results show that all three tools are suitable for agile projects. Especially the automatic checker and simulation glasses worked well in finding accessibility issues and were described as easy to use by the project members. Software organizations should empower their agile project members with low-cost and efficient accessibility testing tools to make their products more accessible for all. Doing this early and often in the development cycle may save the project from potential high costs at a later stage.

The daily stand-up meeting is a widely used practice. However, what is more uncertain is how valuable the practice is to team members. We invited professional developers of a programming forum to a survey and obtained 221 responses. Results show that the daily stand-up meeting was used by 87% of those who employ agile methods. We found that even though the respondents on average were neutral towards the practice, the majority were either positive or negative. Junior developers were most positive and senior developers and members of large teams most negative. We argue that the value of the practice should be evaluated according to the team needs. Further, more work is needed to understand why senior developers do not perceive the meetings as valuable and how to apply the practice successfully in large teams.

Shared knowledge allows virtual teams to collaborate more effectively. Shared knowledge in teams, hereafter called team knowledge, must be established and maintained. This is a key enabler for agile development in a distributed context. Hence, organizations may benefit from efforts to ensure sufficient levels of team knowledge. Such efforts may include different measures, such as project kick-offs, frequent visits across locations, knowledge sharing tools and practices. However, team knowledge includes many types of knowledge, with different impacts on the team's work. This paper outlines a framework for conceptualizing the breadth of team knowledge relevant for virtual software teams. With the help of this framework, organizations can think more strategically about how to improve team knowledge -- for example the planning of kick-offs, what to focus on in face-to-face meetings and how the team members work together on a day-to-day basis. The framework may also be used to assist in planning team composition, for example based on individuals' knowledge and the overlap with other team members' knowledge. The framework uses four broad categories of team knowledge: task-related, team-related, process-related and goal-related. Beneath these four categories the framework details and describes more concrete knowledge types. We also provide examples from software practice for each knowledge type.

Context: Most of the software organizations that use agile methods organize daily team meetings. Aim: Our aim was to understand how daily meetings are conducted and identify obstacles that reduce their efficiency. Method: We observed 56 daily meetings and conducted 21 interviews in three different teams in two countries. We used the repertory grid technique in the interviews and to analyze the results. Results: We identified thirteen obstacles. The four most prominent ones were: (1) The daily meetings lasted too long (on average, 22 minutes instead of the scheduled 15 minutes). (2) In the meetings that were not self-organized, team members reported to the Scrum Master instead of sharing information among all team members. (3) The interruption caused by daily meetings required substantially more time than the actual meeting time due to overhead before and after the meetings. (4) Several team members had negative attitudes towards the daily meetings. Conclusion: Organizers of daily meetings should evaluate whether the obstacles we have identified are present in their organization and consider our suggestions to remove or reduce these obstacles.