Successful extreme programming: Fidelity to the methodology or good teamworking?

ContextDeveloping a theory of agile technology, in combination with empirical work, must include assessing its performance effects, and whether all or some of its key ingredients account for any performance advantage over traditional methods. Given the focus on teamwork, is the agile technology what really matters, or do general team factors, such as cohesion, primarily account for a team’s success? Perhaps the more specific software engineering team factors, for example the agile development method’s collective ownership and code management, are decisive.ObjectiveTo assess the contribution of agile methodology, agile-specific team methods, and general team factors in the performance of software teams.MethodWe studied 40 small-scale software development teams which used Extreme Programming (XP). We measured (1) the teams’ adherence to XP methods, (2) their use of XP-specific team practices, and (3) standard team attributes, as well as the quality of the project’s outcomes. We used Williams et al.’s (2004a) [33] Shodan measures of XP methods, and regression analysis.ResultsAll three types of variables are associated with the project’s performance. Teamworking is important but it is the XP-specific team factor (continuous integration, coding standards, and collective code ownership) that is significant. Only customer planning (release planning/planning game, customer access, short releases, and stand-up meeting) is positively related to performance. A negative relationship between foundations (automated unit tests, customer acceptance tests, test-first design, pair programming, and refactoring) is found and is moderated by craftsmanship (sustainable pace, simple design, and metaphor/system of names). Of the general team factors only cooperation is related to performance. Cooperation mediates the relationship between the XP-specific team factor and performance.ConclusionClient and team foci of the XP method are its critical active ingredients.     

Detecting Coordination Problems in Collaborative Software Development Environments

Software development is rarely an individual effort and generally involves teams of developers collaborating to generate good reliable code. Among the software code there exist technical dependencies that arise from software components using services from other components. The different ways of assigning the design, development, and testing of these software modules to people can cause various coordination problems among them. We claim that the collaboration of the developers, designers and testers must be related to and governed by the technical task structure. These collaboration practices are handled in what we call Socio-Technical Patterns.

The TESNA project (Technical Social Network Analysis) we report on in this paper addresses this issue. We propose a method and a tool that a project manager can use in order to detect the socio-technical coordination problems. We test the method and tool in a case study of a small and innovative software product company.     

The Impact of an Agile Methodology on the Well Being of Development Teams

This paper describes an empirical study, which addresses the aspect of well being amongst members of the software development teams. The question of interest is whether an agile methodology has any distinct effect on the well being of the software developers. Both quantitative and qualitative methods were utilised, including the participative observation, focus group interviews, close-ended questionnaires and simple statistical tests such as Spearman Correlation and Mann–Whitney test. Initial results showed that an agile methodology (XP) has a positive effect on the level of enthusiasm of the software developers in the most dynamic project. To understand why XP can increase enthusiasm, results are interpreted with references to cognitive, affective and managerial properties of the practices studied. This result needs further investigation on the individual effects of each practice on the wellbeing and attitudes of Software Engineering (SE) teams.     

The impact of agile practices on communication in software development

Agile software development practices such as eXtreme Programming (XP) and SCRUM have increasingly been adopted to respond to the challenges of volatile business environments, where the markets and technologies evolve rapidly and present the unexpected. In spite of the encouraging results so far, little is known about how agile practices affect communication. This article presents the results from a study which examined the impact of XP and SCRUM practices on communication within software development teams and within the focal organization. The research was carried out as a case study in F-Secure where two agile software development projects were compared from the communication perspective. The goal of the study is to increase the understanding of communication in the context of agile software development: internally among the developers and project leaders and in the interface between the development team and stakeholders (i.e. customers, testers, other development teams). The study shows that agile practices improve both informal and formal communication. However, it further indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication. The study highlights the fact that hurdles and improvements in the communication process can both affect the feature requirements and task subtask dependencies as described in coordination theory. While the use of SCRUM and some XP practices facilitate team and organizational communication of the dependencies between product features and working tasks, the use of agile practices requires that the team and organization use also additional plan-driven practices to ensure the efficiency of external communication between all the actors of software development.

From Aristotle to Ringelmann: a large-scale analysis of team productivity and coordination in Open Source Software projects

Complex software development projects rely on the contribution of teams of developers, who are required to collaborate and coordinate their efforts. The productivity of such development teams, i.e., how their size is related to the produced output, is an important consideration for project and schedule management as well as for cost estimation. The majority of studies in empirical software engineering suggest that - due to coordination overhead - teams of collaborating developers become less productive as they grow in size. This phenomenon is commonly paraphrased as Brooks’ law of software project management, which states that “adding manpower to a software project makes it later”. Outside software engineering, the non-additive scaling of productivity in teams is often referred to as the Ringelmann effect, which is studied extensively in social psychology and organizational theory. Conversely, a recent study suggested that in Open Source Software (OSS) projects, the productivity of developers increases as the team grows in size. Attributing it to collective synergetic effects, this surprising finding was linked to the Aristotelian quote that “the whole is more than the sum of its parts”. Using a data set of 58 OSS projects with more than 580,000 commits contributed by more than 30,000 developers, in this article we provide a large-scale analysis of the relation between size and productivity of software development teams. Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect. Using fine-grained data on the association between developers and source code files, we investigate possible explanations for the observed relations between team size and productivity. In particular, we take a network perspective on developer-code associations in software development teams and show that the magnitude of the decrease in productivity is likely to be related to the growth dynamics of co-editing networks which can be interpreted as a first-order approximation of coordination requirements.     

A conceptual framework to study the role of communication through social software for coordination in globally-distributed software teams

BackgroundIn Global Software Development (GSD) the lack of face-to-face communication is a major challenge and effective computer-mediated practices are necessary to mitigate the effect of physical distance. Communication through Social Software (SoSo) supports team coordination, helping to deal with geographical distance; however, in Software Engineering literature, there is a lack of suitable theoretical concepts to analyze and describe everyday practices of globally-distributed software development teams and to study the role of communication through SoSo.ObjectiveThe paper proposes a theoretical framework for analyzing how communicative and coordinative practices are constituted and maintained in globally-distributed teams.MethodThe framework is based on the concepts of communicative genres and coordination mechanisms; it is motivated and explicated through examples from two qualitative empirical cases.ResultsCoordination mechanisms and communicative genres mutually support each other. In particular, communication through SoSo supports team members in establishing, developing and maintaining social protocols within the distributed team. Software Engineering tools and methods provide templates for coordination mechanism that need to be adapted and adopted in order to support the project at hand. SoSo serves as a medium for the necessary metawork. The theoretical framework proposed is used to describe both the practices in an established industrial project and the establishing of practices in three student teams. The framework allows explaining the heterogeneity of practices observed.ConclusionsThis paper presents a conceptual framework to study the role of communication through SoSo for coordination in GSD. The usefulness of the framework is supported by empirical findings on the role of SoSo. The theoretical framework can be beneficial for future research that aims to analyze and describe not only the role of SoSo, but also how communicative and coordinative practices can be established and maintained in GSD teams.     

Software architecture-centric methods and agile development

The agile software development paradigm and plan-driven approaches each have their strengths and shortcomings. The former emphasizes rapid, flexible development, while the latter emphasizes project and process infrastructure. Many practitioners, particularly of agile methods, tend-to view software architecture in light of the plan-driven side of the spectrum. They think that architecture-centric methods are too much work, equating them with high-ceremony processes emphasizing document production. But many elements make up a successful development approach, including process, product, technology, people, and tools. Software architecture is part of product quality and isn't tied to a particular process, technology, culture, or tool. This article explores the relationship and synergies between architecture-centric design and analysis methods and the extreme programming framework. We chose to focus on XP because it's one of the most mature and best-known agile practices.     

XP中若干实践的探讨

XP是适合中小型团队在模糊或迅速变化的需求的情况下使用的轻量软件开发过程。文章首先分析了XP中的几个关键实践：简单设计、测试、结对编程和重构，并针对某些应用背景下可能存在的问题提出了相应的修改建议。然后，以举例的方式具体说明如何运用XP的实践。最后，通过XP与传统软件开发方法的比较．分析了XP的主要特征和适用性。     

Evaluation of the implementation of a subset of ISO/IEC 29110 Software Implementation process in four teams of undergraduate students of Ecuador. An empirical software engineering experiment

The competitiveness of software development companies depends on their ability to offer software products with quality attributes within approved budget and schedule. Most Very Small Entities (VSEs) that develop software do not see the benefits of implementing software standards. Consequently, they limit their potential to be recognised as quality software development entities. In this study, the authors present results obtained through the application of empirical software engineering in an experiment in which the ISO/IEC TR 29110–5–1–2 “Software engineering – Lifecycle profiles for Very Small Entities (VSEs) – Part 5–1–2: Management and engineering guide: Generic profile group: Basic profile” was used. The guide includes two processes: Project Management (PM) process and Software Implementation (SI) process. The objective of the project was the development of a software product for the scheduling of medical appointments for the Student Wellness Center of a university of Ecuador. Four teams of undergraduate students were involved. Two of them (controlled teams) implemented a subset of the SI process, while the other two (non-controlled teams) had freedom to choose development activities that were subsequently mapped with the activities of the standard. All teams developed the software product using the SCRUM framework within the same timeframe. Although the experiment was focused on the SI process, the teams also used a tailored version of the PM process defined by the professors. The experiment execution encountered several difficulties. For example, the timeframe of six weeks established in the design of the experiment was too short since students worked part time in the project. All the teams experienced this difficulty, especially when they had to construct and test the software components. Overall, the teams that used the ISO/IEC TR 29110–5–1–2 guide achieved better scores in the quality evaluation of their software processes.     

Motivating developer performance to improve project outcomes in a high maturity organization

In this paper we discuss the impact software developer performance has on project outcomes. Project performance remains unreliable in the software industry with many compromised software systems reported in the press. We investigate the impact that developer performance has on aspects of project success and explore how developer performance is motivated. We present interview, focus group and questionnaire data collected from a team of developers working in a software organization that has been assessed at CMM level 5. Our main findings are that developers value technical skills in their colleagues, but appreciate these especially when supplemented with good human skills. Software developers with a proactive, flexible, adaptable approach who are prepared to share knowledge and follow good practice are said to be the best developers. Motivators for these developers are pay and benefits, recognition and opportunities for achievement in their work. Overall, we found that technical competence, interpersonal skills and adherence to good practices are thought to have the biggest impact on software project success.

A Methodological Framework for Socio-Cognitive Analyses of Collaborative Design of Open Source Software

Open Source Software (OSS) development challenges traditional software engineering practices. In particular, OSS projects are managed by a large number of volunteers, working freely on the tasks they choose to undertake. OSS projects also rarely rely on explicit system-level design, or on project plans or schedules. Moreover, OSS developers work in arbitrary locations and collaborate almost exclusively over the Internet, using simple tools such as email and software code tracking databases (e.g. CVS).All the characteristics above make OSS development akin to weaving a tapestry of heterogeneous components. The OSS design process relies on various types of actors: people with prescribed roles, but also elements coming from a variety of information spaces (such as email and software code). The objective of our research is to understand the specific hybrid weaving accomplished by the actors of this distributed, collective design process. This, in turn, challenges traditional methodologies used to understand distributed software engineering: OSS development is simply too “fibrous” to lend itself well to analysis under a single methodological lens.In this paper, we describe the methodological framework we articulated to analyze collaborative design in the Open Source world. Our framework focuses on the links between the heterogeneous components of a project’s hybrid network. We combine ethnography, text mining, and socio-technical network analysis and visualization to understand OSS development in its totality. This way, we are able to simultaneously consider the social, technical, and cognitive aspects of OSS development. We describe our methodology in detail, and discuss its implications for future research on distributed collective practices.The order of the co-authors names is not significant.     

Enhancing collaborative synchronous UML modelling with fine-grained versioning of software artefacts

Software development teams are composed of people with different knowledge and skills, who contribute to a project from often widely dispersed locations. Software development in geographically distributed environments creates software engineering challenges due to the interaction among members of distributed teams and the management of consistency and concurrency among project artefacts. In this paper, we propose Synchronous collaborative modelling Tool Enhanced with VErsioning management (STEVE) a collaborative tool supporting distributed Unified Modelling Language (UML) modelling of software systems. The tool provides a communication infrastructure enabling the concurrent editing of the same UML diagram at the same time by distributed developers. Complex UML diagrams are decomposed and managed in a fine-grained hierarchy of sub-artefacts, thus providing change and configuration management functionalities for both the diagram and the graphical objects. Thus, software predefined diagram components can be consistently reused and shared across different diagrams of a given project.     

A replicated quasi-experimental study on the influence of personality and team climate in software development

This article reports a replication of a quasi-experimental study analyzing how personality factors and team climate influence software development team effectiveness, product quality and team member satisfaction. The replication was designed on the basis of the original quasi-experimental study, both of which were run in an academic setting. In the original study, data were collected from a sample of 35 three-member developer teams. All these teams used an adaptation of extreme programming (XP) to the academic environment to develop the same software system. In the replication, the data were collected from a sample of 34 three- or four-member developer teams working on the same software project. Student teams used a common object-oriented software development paradigm to solve the set problem and applied the Unified Process. In both studies all teams were formed at random, and their members were blind to the quasi-experimental conditions and hypotheses. The replication of this empirical study aims to verify the results of the original quasi-experiment. It examines, first, whether personality factors (neuroticism, extroversion, agreeableness, openness to experience and conscientiousness) are related to the quality of the developed software and team member satisfaction and, second, whether the preferences, perceptions and preferences-perceptions fit for the four team climate factors (participative safety, support for innovation, team vision and task orientation) are related to the quality of the developed software and team member satisfaction. The results of the replication corroborate some of the findings of the original study. On the one hand, the results revealed that there is a significant correlation between the extroversion personality factor and software quality, but no significant correlation between the extroversion personality factor and team satisfaction. Also, we found that the perception of team climate where participative safety is high is related to better quality software. We observed significant relationships between the perception of the four team climate factors and team member satisfaction. Additionally, the results showed a positive relationship between software quality and teams in which the real climate perception at the end of the project is better than preferences stated by team members at the outset of the project for the participative safety factor. Finally, we found that teams where the real climate is better than the stated preferences for the team orientation factor exhibit a direct and positive relationship to team member satisfaction.     

测试驱动开发在Net环境中的应用

软件测试是保障软件质量的关键，开发者通常都是先写代码后测试，但当时间很紧迫时，测试就变得很困难并且经常被忽略。极限编程最佳实践之一的测试驱动开发在写代码之前先写测试，解决了这一问题，提供了高质量、可测试的代码。介绍了测试驱动开发在．Net环境中的应用。     

Coproduction in successful software development projects

ContextCoproduction of new products has been deemed successful in organizational partnerships by adding to the quality and scope of the product. Techniques that involve users during the development of software tend to mimic this environment, but differ in the type of product and internal client roles. The question is thus, whether coproduction improves the outcomes of a software development project as it has in other disciplines.ObjectiveThis paper evaluates how the coproduction relationship between software developers and users improves the outcomes of a development project. Coproduction is believed to improve outcomes when available knowledge is accessible and applicable to the objective of the development project. Should the relationships hold, coproduction approaches to development can be approached with confidence and improvements made by attention to the development and deployment of expertise.MethodA quantitative questionnaire related to the coproduction environment was developed for four variables to include coproduction, applying expertise, locating expertise, and project success. 128 users from development teams responded to the survey and represent a variety of industries, individual characteristics, and project sizes.ResultsExpertise is crucial to the success of a software development project and coproduction improves the ability to access and apply the needed expertise. In addition, coproduction directly improves outcomes.ConclusionCoproduction can be an effective approach to the development of systems in terms of meeting project goals. Additionally, the assembly of expertise on the team is an important contributor to successful outcomes that may be enhanced through effective selection of team members. The ability to locate the available expertise is crucial, indicating the value of team building functions to promote awareness of expertise location.     

Agile software testing in a large-scale project

Agile software development in general and Extreme Programming (XP) in particular, promote radical changes in how software development organizations traditionally work. We present and analyze new data from a real, large-scale agile project to develop a business-critical enterprise information system for the Israeli Air Force (IAF). Our results offer new evidence that agile testing practices actually work, dramatically improving development quality and productivity. We describe the organization's successful practices and guidelines in four key areas: test design and activity execution, working with professional testers, planning, and defect management.     

Towards understanding the relationship between team climate and software quality—a quasi-experimental study

This paper describes an empirical study that examined the work climate within software development teams. The question was whether the team climate in software developer teams has any relation to software product quality. We define team climate as the shared perceptions of the team’s work procedures and practices. The team climate factors examined were West and Anderson’s participative safety, support for innovation, team vision and task orientation. These four factors were measured before the project using the Team Selection Inventory (TSI) test to establish subject climate preferences, as well as during and after the project using the Team Climate Inventory (TCI) test, which establishes the subject’s perceptions of the climate. In this quasi-experimental study, data were collected from a sample of 35 three-member developer teams in an academic setting. These teams were formed at random and their members were blind to the quasi-experimental conditions and hypotheses. All teams used an adaptation of extreme programming (XP) to the students’ environment to develop the same software system. We found that high team vision preferences and high participative safety perceptions of the team were significantly related to better software. Additionally, the results show that there is a positive relationship between the categorization of better than preferred, as preferred and worse than preferred climate and software quality for two of the teamwork climate factors: participative safety and team vision. So it seems important to track team climate in an organization and team as one (of many) indicators of the quality of the software to be delivered.

Data collection in global software engineering research: learning from past experience

Global Software Engineering has become a standard in today’s software industry. Research in distributed software development poses severe challenges that are due to the spatial and temporal distribution of the actors, as well as to language, intercultural and organizational aspects. These challenges occur in addition to “traditional” challenges of the domain itself in large-scale software projects, like coordination and communication issues, requirements volatily, lack of domain knowledge, among others. While several authors have reported empirical studies of global software development projects, the methodological difficulties and challenges of this type of studies have not been sufficiently discussed. In this paper, we share our experiences of collecting and analysing qualitative data in the context of Global Software Engineering projects. We discuss strategies for gaining access to field sites, building trust and documenting distributed and complex work practices in the context of several research projects we have conducted in the past 9 years. The experiences described in this paper illustrate the need to deal with fundamental problems, such as understanding local languages and different cultures, observing synchronous interaction, or dealing with barriers imposed by political conflicts between the sites. Based on our findings, we discuss some practical implications and strategies that can be used by other researchers and provide some recommendations for future research in methodological aspects of Global Software Engineering.     

Information Alignment and Task Coordination in Organizations: An 'Information Clutch' Metaphor

Despite their rising popularity, distributed teams face a number of collaboration challenges that may potentially hinder their ability to productively coordinate their resources, activities, and information, often in dynamic and uncertain task environments. In this paper, we focus principally on the criticality of information alignment for supporting coordinated task performance in complex operational environments. As organizations become more expertise, geographically, and temporally distributed, appropriate alignment and coordination among distributed team members becomes more critical for minimizing the occurrence of information flow failures, poor decision-making, and degraded team performance. We first describe these coordination processes using the metaphor of an 'information clutch' that allows for smooth transitions of task priorities and activities in expert teams. We then present two case study examples that illustrate the potentially significant impact of information sharing and information alignment on productivity and coordination in organizations. We conclude with a discussion of future directions in this area.     

Acceptance of software process innovations – the case of extreme programming

Extreme programming (XP), arguably the most popular agile development methodology, is increasingly finding favor among software developers. Its adoption and acceptance require significant changes in work habits inculcated by traditional approaches that emphasize planning, prediction, and control. Given the growing interest in XP, it is surprising that there is a paucity of research articles that examine the factors that facilitate or hinder its adoption and eventual acceptance. This study aims to fill this void. Using a case study approach, we provide insights into individual, team, technological, task, and environmental factors that expedite or impede the organization-wide acceptance of XP. In particular, we study widely differing patterns of adherence to XP practices within an organization, and tease out the various issues and challenges posed by the adoption of XP. Based on our findings, we evolve factors and discuss their implications on the acceptance of XP practices.