No abstract

582This article describes how observational methods were used to ascertain the effect of conflict on the performance of software engineering (SE) teams during the important feasibility, requirements analysis, and design phases of software projects, and the subsequent development of social and conflict interaction protocols to allow researchers to record conflict episodes when they occurred. Three teams consisting of master of science (MSc) students at the University of Sheffield were observed as they worked through the feasibility, analysis, and design phases of the SE life cycle. Each occurrence of conflict between team members was recorded, as well as the form and intensity of the conflict.There were several reasons for pursuing this line of research. The first is that commercial SE is a team-based activity, and, as in other related contexts, success is dependent to a large extent on whether or not team members have succeeded in establishing a cooperative environment (Cohen & Bailey, 1997). Additionally, several scholars have opined that the social factors of SE are potentially more important than the technical aspects (Curtis, 1991(Curtis, , 1998Curtis, Krasner, & Iscoe, 1988;Curtis, Walz, & Elam, 1993). This view is reinforced by other scholars who hold the belief that future SE research should focus more on human factors (Crowston & Kammerer, 1998a, 1998bPetre, Budgen, & Scholtz, 2004). The rationale behind this argument is that further exploration into these areas will play an important role in the maturation of SE as an academic discipline.The importance of teamwork in SE has long been recognized at a pedagogic level. It is now common for SE degree programs to include one or more team projects. These projects should enable team members to develop what has been termed positive interdependence (Johnson & Johnson, 1978), which theoretically should result in enhanced short-term memory, long-term retention, greater understanding of course material, and critical thinking and problem-solving skills.Although there are numerous advantages to working in teams, there are also several problems that one needs to be aware of (Harris & Looney, 1999). Harris and Looney stated that one of the main problems is that a team approach to a project usually generates a greater degree of conflict than many people are accustomed to. This conflict can be a serious impediment to performance.This situation raises the question of what the exact nature of conflict actually is. Some (Amason, 1996;Galinsky, 2002;Jehn, 1995) have argued that conflict is an inevitable and pervasive aspect of organizational life. People are said to be in conflict when the actions of one person are interfering, obstructing, or in some other way making another's behavior less effective (Tjosvold, 1997).Previous team-process research has distinguished three separate forms of conflict: task (or cognitive), relationship (or affective) (Amason, 1996;Amason & Schweiger, 1994;Pinkley, 1990), and process (Jehn, 1995). These forms of conflict have been found to have ...

This paper describes ethnographic observations and analysis of the performance of student teamsworking on year-long software projects for industrial clients. Personality types were measured using an online version of the Myers Briggs Type Indicator (MBTI), as a basis for studying how individuals interacted within the teams, and the effects of disruptive issues on the quality of work produced by the teams. Aspects recorded included the effect of personality type on behavior towards team mates and how this related to the amount of disruption, and the numbers of positive ideas brought forward from each member. A significant finding was that issues which teams did not discuss adequately caused more problems for the quality of work than issues which produced actual disruption within the team.

If empirical software engineering is to grow as a valid scientific endeavor, the ability to acquire, use, share, and compare data collected from a variety of sources must be encouraged. This is necessary to validate the formal models being developed within computer science. However, within the empirical software engineering community this has not been easily accomplished. This paper analyses experience from a number of projects, and defines the issues, which include the following: (1) How should data, testbeds, and artifacts be shared? (2) What limits should be placed on who can use them and how? How does one limit potential misuse? (3) What is the appropriate way to credit the organization and individual that spent the effort collecting the data, developing the testbed, and building the artifact? (4) Once shared, who owns the evolved asset? As a solution to these issues, the paper proposes a framework for an empirical software engineering artifact agreement, which is intended to address the needs for both creator and user of such artifacts and should foster a market in making available and using such artifacts. If this framework for sharing software engineering artifacts is commonly accepted, it should encourage artifact owners to make the artifacts accessible to others (gaining credit is more likely and misuse is less likely), and it may be easier for other researchers to request artifacts since there will be a well-defined protocol for how to deal with relevant matters.

The goal of this article is to describe how ethnographic methods were used to study software engineering (SE) teams for the duration of specific projects, in order to gain a greater understanding of the role of human factors over the duration of an industrial SE project. Group interaction styles affect communication and, thus, team performance by facilitating or hindering the exchange of information among group members. An issue requiring further study was how constellations of personality types are manifested in team interaction styles.Taking this into account, the work described here also had another dimension, which was to study how particular combinations of individual personalities, as measured by an online version of the Myers-Briggs Type Indicator (MBTI), might either promote effective teamwork or cause clashes and, second, how these clashes might disrupt the operations of an SE team.The personal interest behind this research lies in teams and the psychological aspects of SE. Most SE projects are carried out by teams of varying size, working mythical man months (Brooks, 1975), in often feverish attempts to meet project deadlines. Teams outperform individuals acting alone or in larger organizational groupings, especially when performance requires multiple skills, judgments, and experiences. A team is more than just several people working on a common project, although the level of teamwork will vary from one team to another. Teamwork represents a set of values that encourage such behaviors as listening and constructively responding to points of view expressed by others, giving others the benefit of the doubt, providing support to those who need it, and recognizing the interests and achievements of others. The importance of teamwork in SE has been recognized at a pedagogic level. Many undergraduate courses now have group projects as a central part of their syllabus. These projects can vary from carrying out the theoretical analysis and design of a system to the analysis, design, and implementation of a system for an external industrial client.A computer-based system is built for people and by people, it is intended to serve some human purpose, and it exists in some human context. Some of the most vexing difficulties involved in SE projects are social, political, or cultural, and social issues are inherent to the requirementsengineering process. The work carried out by the present authors was not limited to understanding requirements engineering but was intended to encompass the entire SE project lifecycle.So far, the authors have studied the operation of teams throughout complete projects, measuring the levels of disruption that different issues have caused to the team, and have shown how these disruptions can be related to personality clashes between individuals within the teams (Karn & Cowling, 2004a, 2004b. Although there are numerous advantages to working in teams, there are also several problems that could pose a potential risk to SE teams, since a team approach to a project usually generates a greater ...

No abstract

No abstract

No abstract