Patterns of Interaction in Same-Time, Same-Place Collaborative Programming

TR93-006

October 1993

Eileen Kupstas

The University of North Carolina at Chapel Hill Department of Computer Science CB#317 5, Sitterson Hall Chapel Hill, NC 27599-3175 919-962-1792 jbs@cs.unc.edu

A TextLab/Collaboratory Report

Portions of this work were supported by the National Science Foundation (Grant #IRI-9015443 and by IBM Corporation (Sur Agreement #866).

UNC is an Equal Opportunity/Affirmative Action Institution.

Table of Contents

Overview and Purpose .................................................... : ..................................... 1 Description of group and setting .......................................................................... 1 Details of the Study .............................................................................................. 3 Results ................................................................................................................. .5

Roles in group .......................................................................................... 5 Communication patterns within the group .............................................. ? Resources ................................................................................................. 1 3 Interaction Types ..................................................................................... 1 7

Formal Interactions ..................................................................... 1 9 E-mail .......................................................................................... 2 0 Informal Interaction .................................................................... 2 2

Purposes of communication ............................................. 2 2 Methods of communication ............................................... 2 2 Purpose and method in use ............................................... 2 3 Individual differences ...................................................... 2 8 Time .................................................................................. 28

Meaning for collaborative tools ........................................................................... 2 9 Summary and conclusion ...................................................................................... 3 1 Acknowledgements ................................................................................................ 3 2 References .......................... : ................................................................................. 3 3

Overview and Purpose

This paper presents a description of collaborative interactions in a software development group during a three-month, full-time development effort. The observations were undertaken with the goal of determining how software development groups collaborate in their natural environment. By making these observations, we can better understand how groups work together. This understanding will help in the design of computer-based collaborative systems that will successfully aid and support the collaborative process.

Tools to support collaborative work must meet the underlying needs of group communication. In order to design systems to support group interactions, we need to know a number of things about why group members communicate with each other. Questions can be asked about a variety of aspects, including roles group members played, how group members interacted and for what purpose, the use of available resources in the interactions, and patterns of communication that developed within the group.

One of the first questions to ask is why group members communicate with each other. Do they need to share information? Do they need to work on common artifacts or share a physical resource? Are these interactions primarily about the work itself or are some interactions more social in nature? The answers to these questions tell us what type of tools would be needed within a collaborative system.

The next set of questions we need to answer deal with how group members interact. Do they prefer being co-located or do they merely need to talk to each other? How many people typically work together at one time? Do the group members' roles affect how they interact and with whom? Do members prefer being co-located even when working in individual task? Do the participants change over the course of an interaction? These questions address the configuration of a collaborative system.

Other questions concern how often interactions happen. How many interactions typically occur in a group and how often? How much time do group members spend working together as opposed to working individually? How long might an interaction last? The answers to these questions can provide an idea of the amount of communication that must be supported for effective collaboration.

The purpose of this report is to provide a high-level look at the interactions of one collaborative group and see how this information can affect the design of collaborative systems. Though each group will vary in how members work together, the questions considered here are broad enough to provide some general ideas for consideration. A more detailed look at the interactions will be given in a separate technical report.

Description of group and setting

This study covers a three-month period of software development in an on-going project. My role was as a participant-observer; that is, I was a full member of the development team with a designated job, sharing the goals and deadlines of the project, while spending a portion of my time observing the group and the interactions. This allowed me to understand the context for group interactions, how portions of the project fit together, and the influence of project-related events on the group work and interactions.

The group consisted of seven people, all graduate students in the Computer Science Department at UNC-CH. One person was not officially a member of the development team but had significant interactions with the development group, since the work of the group depended on this programmer's work. For purposes of this analysis, I consider this person an honorary member of the group. Team members worked full-time on this project (40 hours per week}. The task was to begin work on a robust . version of a prototype application completed the previous semester by a portion of the

1

same team. The goal for the summer was to have the skeleton of the new version running, with the rest to be finished over the next two semesters with team members working half-time. Thus, there was incentive to build a strong sense of team identity and to produce as much as possible in the three months.

The leader was appointed by the lab director to run the development group, having lead the previous development team. He 1 and another team member had worked on the prototype version. This other experienced member became the technical "guru" for the group. Another two members had worked in the same research lab but not on this particular project nor with this particular group. These members were "on-loan" from other lab projects for the duration of the development effort. The last two members were new to both the lab and the software development group. The honorary member was a long-time member of the research lab and worked closely with the development team on system issues. Most of the team members knew each other previously from classes or other work and were comfortable working together.

The group leader used a democratic2 style [Lewin]. All issues were open for discussion and most were brought up in meetings for group discussion. The leader had responsibility for administrative tasks, long term scheduling, and the integration of work. During meetings, the leader acted more as a moderator and technical expert. Meetings were often used to explain issues to group members so that a consensus could be reached. Specific tasks were assigned to each member but usually only after consulting the member's preferences; exceptions occurred with high priority tasks or tasks requiring particular expertise. In this case, the leader usually apologized for having to make the assignment. The leader was concerned that everyone knew where they fit in the overall plan, was satisfied with their working conditions, and did not spend too much time in frustration ("banging their head") on a difficult problem before seeking help. Even under reasonably tight deadlines, the leader did not expect much overtime; he mainly encouraged efficient use of the time available.

During working hours, group members spent much time on communication. Members asked each other many questions, volunteered information, and had social/recreational interactions. Difficult technical problems were generally discussed with at least one other group member; often the whole group became involved. Negative comments were received well. The leader, as stated above, sought feedback and accepted negative comments gracefully. Personal initiative was encouraged and praised, though occasionally funneled in a slightly different direction than the initiator envisioned. The group was very open about both work and social communications. As discussed in a later section, members felt free to walk over and look at what another person was doing, offer unsolicited advice on a problem, or join in any discussion taking place within the group. Group morale seemed high with few grumblings or complaints. As evidence, all but one member remained with the team during the next semester. The one member who did not remain with the group left for reasons unrelated to the specific job.

Physical Set-up

The group worked in the same lab during the day. This was by agreement, after a suggestion from the leader. The leader felt that work would be more productive if all

1 The use of the masculine and feminine will be used interchangeably throughout the document when a neuter pronoun cannot be used; this is not to be taken as an indication of the gender of the team member.

2Lewin divided leadership styles into democratic, autocratic and laissez-faire. Democratic leaders do not necessarily run an organization by voting; however, the group is involved in the decision making process. In the other cases, the leader is uninvolved (laissez-faire) or completely in charge (autocratic).

2

team members were available to each other for questions and help. The layout of the lab is given in Figure 1. Five members worked on the adjacent five machines (I will call this area the "U"), one member worked on the other marked machine in the lab, and the honorary member usually worked outside the lab. Both the honorary member and the member working outside the U were treated as geographically remote by other members; group interactions with these two members were different than the interactions among members in the U. (This will be discussed more fully in the later section "Communication Patterns".) The work time of members during each day overlapped from roughly 10 am to 4:30 pm. Lunch time ranged from 11 :30 to 1 :00, though many team members chose to eat at their workstation. Given all this, the period with all members in the lab was roughly five hours a day.

Project Timeline

The project was divided into two parts: orientation and real work. Part of the project was to rewrite the existing functions in a new language. During the first three weeks, the group spent most of its time learning new tools and the new language. Each person had an assigned task; however, the steepness of the learning curve was acknowledged, and no one was seriously expected to make much progress on their task. A large proportion of group members' time was spent meeting to help each other with questions and problems. Also, not all members of the team were back to work until the beginning of the third week. Once the orientation period was over, meetings became much less frequent. By this time, group roles had solidified and seating patterns in the lab were stable. Much more time was spent working individually, though interactions were still frequent.

Details of the Study

My primary role with the team was as a team member, not as an observer. spent all my work time with team members in the lab. My programming assignments took up roughly one-half to two-thirds of my work time; the rest of the time was used to record data or observe interactions. All group members knew of my dual role and were comfortable with this arrangement.

The observation period was three months in order to give the group time to reach a stable pattern of behavior. The seating preferences of the group were stable after the first month, as were the group roles. Variations occurred, but these were not major and usually attributable to some particular event.

Data was gathered in an informal manner for the first month, due to the initial orientation period. I made notes of group interactions and formal meetings during this time but did not try to collect information in accord with any hypothesis of group interactions. Once the group's behaviors had stabilized, I could collect and organize the information in a more coherent way. I began to focus on a set of interactions that seemed to cover the interactions of the group. Since this is an exploratory study, I did not try to filter and organize the data in any way before recording it. The results in the next sections come from later analysis of all the data.

The video taping was done towards the end of the three month period so that the group members would be firmly established in their roles and less bothered by the video taping. The taping was done for six hours, from 10:00 am to 12:00 pm and 1 :00 pm to 5:00 pm, on two days in order to catch the widest scope of behaviors. The video camera did not seem to disturb the group members after the first half-hour; one group member almost walked into the camera on two occasions. The group interactions recorded on the video tape were typical for the group and did not point up any behaviors I had missed during the prior, manual data collection.

3

White board Door

7

L Whiteboard

KEY:

Figure 1: Layout of working area

0 0 0 Conferenc Area o o~o

~ 0

10 Q(~

Member seat: • Workstation usable e for this project Whiteboard

Other seats: 0 Other workstations 0 not usable for this project

4

The resulting observations in this paper are my understanding of the group process as represented by the data gathered. Specific numbers and percentages come from two sources. The hand-recorded observations made over the entire three-month observation period are the source of the numbers for meetings and e-mail communications. Data on the informal, unscheduled interactions comes from twelve hours of videotaped observations, which made more precise counts and timings practical. These sources are noted in the relevant sections.

Results

Through the observations, the various roles of each group member became apparent. These roles influenced the communication patterns within the group and the specific jobs performed. Though there was a designated leader, a number of group members performed leadership functions at various times. This lead to a communication pattern with no strong centralized center at the leader; our communications were distributed among all the group members.

The physical distance between group members also influenced communication. The farther away a group member sat, the fewer interactions that group member was involved in. The number of project-related interactions was greater than the non-project-related interactions for the geographically remote members; in the case of the most remote member, there were no non-project-related interactions. Specific numbers are given in the section on communication patterns within the group.

In order to do their work, group members shared large amounts of information with each other. Some of this was handled verbally, but a number of interactions relied upon group members being able to share their workstation resources. Sometimes group members just looked at each others screens, but, at other times, people pointed to each others screens to indicate particular lines of code or operated each others mouses and keyboards. In some cases, team members programmed on each others workstations or participated in joint programming at one workstation. This sharing of resources was important to the way the group worked.

The group members communicated for a number of reasons and used various means to interact. Some interactions were specifically related to the project tasks at hand, whereas others served to build group camaraderie and keep morale high. Some interactions required that participants move in order to be near each other, but other communications could be made by yelling across the room to each other. A few interactions had no verbal communication, but rather team members looked at each others work and perhaps pointed to a specific section. These various purposes and methods of communication can be categorized and compared to gain some insight into the "how and why" of this group's interactions.

The following sections give a detailed discussion of the various factors that influenced how this group worked together. A detailed explanation of the group roles is given. We also look at the communication patterns within the group and their relation to the physical location of group members. Information on what resources group members shared and how they shared them is given. Finally, I present a categorization of the group's interaction methods and purposes, with a count of interactions for each of the categories.

Roles in group

Each member of the group specialized in a particular area of the task, though the knowledge of all the group members overlapped at various points. Solutions to problems often required two or more people since, by the nature of the work, there were many overlapping parts. No doubt, this was a factor in the high rates of interaction within the

5

group. The group members chose the particular role they were to play in the group, with the exception of the leader. The main roles taken by group members were leader, technical guru , tool builder, socio-emotive leader, historian , system co-ordination, and problem consultant.

As discussed in [Bales], our group had a task leader and a socio-emotive leader. The duties of these two leaders differ. The task leader is responsible for seeing that needs of the project are taken care of, deadlines are met, and all members are working on their tasks. The socio-emotive leader is the emotional center of the group, providing for other non-task needs in the group, so that the group remains a cohesive working unit. In our particular group, the assigned leader was also interested in the socio-emotive factors of the group. This was indicated by the democratic leadership style; all issues were open for discussion and most were brought up in meetings to discuss. The leader acted more as a moderator and technical expert, and meetings were mainly used to explain issues to group members so that a consensus could be reached. When the leader was not present, the two leadership roles were generally split between the socio-emotive leader and the technical guru. All three group members were important in maintaining a successful working environment.

The leader's role has been described above; the job, as handled within this group, was loosely defined and included mainly coordination of tasks. The technical guru had worked on the previous version of the program and was often given the technically challenging programming assignments. She was consulted on issues that required a deep understanding of the programming language and Unix and would offer suggestions about how to approach a problem and help debug difficult pieces of code. The tool builder was responsible for writing supporting code that other lab members needed. This job required much flexibility in working on whatever needed to be done at that time. The socio-emotive leader concentrated on building the "team spirit", keeping group morale high, and smoothing over difficulties that arose. This team member did write a large amount of code but seemed to have an overriding interest in the group's welfare. The historian kept track of why particular decisions were made within the group and reminded the group of prior decisions that influenced current work. This programmer had been involved with the Golab for a long time and consequently knew the context into which the group's work fit, so he sometimes reminded the group of the theoretical and practical ideas that shaped the current task. The system coordinator worked on the interfaces between the various tool kits being used on the project. Sometimes the project required that an underlying tool kit be modified to support a necessary functions or that a means of accessing lower level functions be written; the system coordinator handled these tasks as well as other programming assignments. The problem consultant was called on to handle various problems that arose in using the programming language or in interfacing to other code written in the Colab. He was called on as needed to handle various situations, though he did not have a explicit programming assignment within the group.

These roles were not exercised exclusively by any one person; at various times all group members played each role. There was a high degree of overlap in the group members' knowledge of the project and in the roles each member played in the group. For example, the technical guru often took a leadership role, especially when the leader was absent, and the historian was often consulted as the technical expert for his particular field of expertise. The socio-emotive leader handled some of the tool building jobs and some leadership duties. As stated in the previous sections, the leader was also concerned with the socio-emotive aspects of the group. This allowed the group to function smoothly when one member was absent; however, in normal circumstances, a particular group member usually played a particular role in the group.

6

Communication patterns within the group

The amount and type of interaction varied from person to person within the group. This was influenced by a number of factors, including the particular role a person had in the group. For the following discussion, I have broken interactions into several groups. Technical interactions were directly related to the project, the schedule, or the requirements. Non-technical interactions are primarily social or recreational in content. All other interactions can be considered together, for the moment, in the group everything else. This group constitutes a small percentage of the interactions and will be discussed in detail later in the section on Informal Interactions. The numbers used in this section were taken from the twelve hours of videotaped group working time, which had a total of 144 interactions; two of these interactions are omitted because they involve people outside the group, leaving 142 interactions for this section.

Figure 2 shows the total bandwidth between any two members (if any). The width of the arrows is proportional to the number of communications between the two members, and the arrow indicates the direction of communications. The arrow begins with the initiator of the interaction and points to the recipient of the interaction. A double-headed arrow indicates that both initiated communications at some point. (For example, if Mary says "Mark, what file were you working on?", the initiator is Mary and the recipient is Mark.) Here, we can see that the leader was involved in a large number of interactions with all group members. In contrast, the problem consultant, as one of the geographically remote team members, interacted mainly with the leader and no one else, with the exception of being the recipient of some interactions from the socio-emotive leader. The socio-emotive leader and the technical guru had some contact with all other group members, though somewhat less than the leader did. The system coordinator, the other geographically remote member, interacted somewhat more with the technical guru than with the leader. The historian and the tool builder interacted some with the group members that sat within the U and none with the two geographically remote members, the system coordinator and the problem consultant; a larger portion of the interactions were with the leader, with a smaller number of interactions with the socio-emotive leader and the technical guru.

Figure 3 shows the numerical distribution of communication initiations and receivings within the group. Just considering the total number of interactions for each team member as given in the last column, the results support the often found effect of status on communication patterns [Bales]. The leader both initiated and was the recipient of more interactions than other members. The leader was involved in a total of 7 4 interactions, or 24%, as either the initiator or the receiver. The next highest was the technical guru who was involved in 66 interactions, or 22%. The third highest in involvement was the socio-emotive leader, who had a part in 65 interactions, or 21%. These three group members had significantly higher participation than the average value of 14%, as would be expected by their roles in the group. The two geographically remote members, the system coordinator and the problem consultant, participated in only 5% and 3% of the interactions, respectively. In the second and third columns of Figure 3, the interactions have been divided into two groups, technical and other. Technical interactions are directly related to the project as described above, whereas the other category includes the all other types of interactions (the non-technical and every1hing else categories). As would be expected, the leader had the highest number of interactions of both types. The leader's interactions are approximately 47% non-technical, the guru's about 33%, and the social leader's roughly 54%. This is consistent with the specific roles of these members. (The 51% rate for tool builder is an artifact of an unusual social event on one of the videotaping

7

Techni::al Guru

Problem Consultan-

Figure 2 : Total bandwidth between group members. The line width is proportional to the total number of communications between two members. The arrow begins with the initiator and points to the recipient. A double-headed arrow indicates that both members initiated interactions.

8

lnit iated Recieved Total Total

Person by type

T ntho>r T Other T Other

Leader 16 22 23 13 39 35 74 Socio-emoti ve Leader 14 16 21 14 35 30 65 Technical Guru 14 13 30 9 44 22 66 Historian 9 2 18 10 27 12 39 Tool Builder 13 10 4 8 17 18 35 System Coordinator 7 1 5 3 12 4 16 Problem Consult ant 5 0 4 0 9 0 9

78 64 105 57 183 1 21 304

Figure 3 Interactions for each group member categorized as technical (T) or other (non-technical and everything else).

days; this was an abnormally high amount of social interaction for this group member, based on previous observations.) In contrast, the problem consultant and system coordinator mainly participated in the technical interactions. The system coordinator, who sat in the lab but not in the U, participated in a small number of interactions that were not technical, while the problem consultant, who did not sit in the lab, participated in none. This indicates a strong correlation between the physical distance between lab members and the number of less technical interactions between them.

Figures 4 and 5 show the communication bandwidth between members, based on the numbers given in Figure 3. In Figure 4, we can see the high amount of technical communication involving either the leader or technical guru. The leader had technical interactions with all group members and the technical guru had technical interactions with all but one of the team members. Note that all group members participated in some technical interactions, though not necessarily with very many of the other members. For instance, the problem consultant dealt mostly with the leader and not with the other group members, while the socio-emotive leader had technical interactions with all but one member of the group. From Figure 5 we can see the central role played in other communications by socio-emotive leader. Both of these figures highlight the non-centralized communication pattern that arose within our group, as well as the difference in the purpose of interaction among the various group members. Figure 6 shows the interactions in the non-technical category only; these interactions

are mostly social or recreational in purpose and are a subset of the other category. In this picture, it is easier to see the strong role played by socio-emotive leader. From observations of the group when the leader was present and when absent, I can add supporting data for socio-emotive leader's social role. When the leader was present, the social aspects of the group were fairly evenly divided between the leader and ·

9

Technical

System Coordinator

Technical Guru~

Leader

Historian Tool Builder

Problem Consultant

Figure 4: Total proportional bandwith in technical interactions.

1 0

Other

Historian 0 Problem Consultant

Figure 5: Total proportional bandwidth for non-technical interactions.

1 1

Non -technical only

Socio-emotiv e Leader_.......,,._ __

Historian Too I Builder

Leader

0 Problem Consultant

Figure 6: Total proportional bandwidth for non-technical interactions.

1 2

socio-emotive leader, and the leader handled all of the task-related leadership duties. When the leader was absent, however, the task-related duties were assumed by technical guru and the social part assumed by socio-emotive leader.

From Figures 5 and 6, the relative isolation of the geographically remote group members becomes apparent. The system coordinator and the problem consultant did not work in the small U-shaped group of terminals. One of these group members sat somewhat removed from the group but in the same room (see Figure 1 for the room layout), while the other usually sat in an office on the same floor. Even at the small distances of 15 feet and 50 feet, the rate of interaction drops off severely. Group members chose where to sit so the effect could be due to distance or to personality. The effect, however, is quite strong. These group members had primarily technical interactions with the group. They were less likely to have purely non-technical interactions at all, and, if they did, it was more likely at their own initiative. This could have repercussions in a working group that is not able to overcome the perceived distance, even though, in our case, the distances could be measured in feet.

The specific pattern of the communication network is hard to determine precisely. A major node is obviously the leader, with the technical guru and the socio-emotive leader forming secondary nodes. The high rates of communication maybe hiding the true structure of the underlying network. One surprising result in the communication pattern, though, is the lack of strong effect for proximity. Members sitting next to each other were not much more likely to interact than any other pairings, with the exception of the geographically remote members. This may be due to the large number of communications with the leader or to the close seating in the lab, which meant that each member was effectively "next to" each other member for communication purposes.

Some of the differences in interaction rates among group members may have been due to group members' native languages. This group had roughly half the members sharing one native language and half another. The common language for work was English but not all group members were equally comfortable with it. In our case, the seating arrangement was fairly well mixed both within the U and for geographically remote team members; so for our group, native language does not account for the drop in technical interaction rate with distance. The number of technical interactions for each group member show no correlation with native language. For non-technical interactions, some group members primarily interacted with those who shared their native language. Due to the small group size and the interdependence of all the work, the effect is not strong.

Resources3:

The group members often looked at each other's work and discussed it. Being able to share the same computer screen to talk about a problem or draw a picture on the whiteboard and work on the information was important to many of the group's interactions. The physical representation served as a focus of the interaction and allowed participants to clarify parts of the discussion or work in a common context. Here, I consider the use of personal resources -- the computer screen, mouse, and keyboard of a workstation or paper and pencil -- as well as the common resources of the group, such as the whiteboard.

The group's meetings mostly occurred in meeting area within the lab that had a whiteboard available (see Figure 1 for a layout of the room). The board was used as a place to put reference information, such as lists of tasks to be done or information relevant to the problem under discussion, or as a working space for considering various ideas. Though the leader generally presided at meetings, handling the organizational

3 This question was suggested by Don Smith.

1 3

tasks and keeping notes on the whiteboard, all group members were free to write their ideas or to add to someone else's work on the board. The board was used more as a common workspace for the group than as a personal workspace for the leader.

The other types of resources were most commonly used outside of meetings. Of the 144 interactions captured on videotape, 64 of these involved the use of resources; that is, group members used a computer screen, mouse, keyboard, or the whiteboard as an important part of their discussion for almost half (44%) of their interactions. Based on my long-term observations, this value is consistent. For these 64 events, I counted any time that one person looked at another's screen as well as anytime that someone interacted with another's screen through pointing, using the mouse, or by typing. These numbers also include use of the whiteboard, paper and pencil, and such, if that was combined with screen use. Most of these events have two participants, though some involve more than two people. In this section, I will continue to look at the initiator and recipient of the interactions. I also consider the owner of the resource (the person who originally controlled the resource) and the non-owner (the person who uses a resource initially controlled by another person).

Figure 7 gives a rough breakdown of the interactions involving resources, with specific numbers given in Figure 8. The first group in Figure 8 shows the interactions in which the non-owner just looked at another person's (the owner's) screen. These interactions did not involve physical use of the resources, such as pointing to the screen or manipulating the mouse or keyboard. (Here again, I use the categories of technical, non-technical, and other to group the communications by their content.) This type of interaction occurred when a group member had a quick question concerning the programming language, when someone found an interesting section of code or a funny piece of documentation, or for such non-technical events as watching another group member play a computer game. This accounted for 34% of the interactions involving resources or 15% of the total interactions, as shown in Figure 7.

The second group shows the interactions in which the non-owner pointed, usually with a finger, to the screen of the owner. This group accounts for 27% of the interactions involving resources or 12% of the total interactions. These interactions were usually more involved, though some were quick pieces of advice on syntax or game playing strategies. Examples include joint code debugging, explanations of structure of pieces of code written by one of the participating programmers, or discussions focusing on a single line of code.

The last group contains the interactions in which the non-owner used either the mouse or keyboard of the owner. These interactions were usually detailed discussions about particular sections of code, with manipulation of the text by both programmers; sometimes these became joint programming sessions where the participants shared the resources in order to work on the same piece of code together. This is 39% of the interactions involving resources, or 17% of the total interactions as shown in Figure 7. Some of the 25 interactions in this group can be categorized further. These distinctions are based on other contextual information available and provide a clearer picture of what was happening. Four events involved explicit permission of the owner, with the owner handing the keyboard to the non-owner. Two events were true joint programming with two or more users sharing a keyboard/mouse back and forth. Three were based on "indirect operation" • the non-owner asked the owner to type/do something. I counted this as an instance of manipulation since the non-owner was in control. In one case, mouse operation was due to proximity to the mouse; the non-owner would have had to reach across the owner to point to something on the screen. One keyboard/mouse use by a non-owner seemed to be due to expertise/authority of the non-owner; the non-owner just started typing/mousing with no objection by the owner after the owner asked a question. Two events used multiple screens, one for each participant. The participants moved back and forth to compare screens or point to portions of a screen. One of these. events had whiteboard use also, as an intermediate step. Code was put on the whiteboard

1 4

Initiated as:

Look only

Look/point

Look/point/ type/mouse

No resources used

56%

Look Only

15%

Pointing wlo mouse

12%

Mouse/k eyboard used

17%

Figure 7: Percentage of events by resource usage.

Technical Non-technical Other

13 5 4

13 4

20 5

46 14 4

Figure 8: Interactions involving shared resources

Total

22

17

25

64

1 5

then copied to another terminal. The details indicate that it was a translation process, with new code being generated based on the old code.

As might be expected, the interactions which involved more resources lasted a longer period of time. The total time spent in interactions from the videotaped sessions was 339 minutes 55 seconds, or a little over live and one-half hours4. Of this time, almost 75% (254 minutes and 25 seconds} was spent in interactions that involved resources, as shown in Figure 9. This highlights the important role resources played in the group's interactions. A large portion of the time was spent in interactions in which the non-owner shared the resources of the owner. In Figure 9, we can see that almost half the interaction time involved shared resources. This is important information in designing computer systems for collaborative work. For our group, a system would need to support manipulation of the contents by all the participants, not just by the owner. Though shared systems are more difficult to build, the users may find them necessary to their work.

Group members moved around as necessary to use resources. In 25 of the 64 interactions involving resources, one or more group members specifically moved from their current location to a particular resource (usually a terminal or whiteboard) to work. As would be expected, movement was more likely if the participants wanted to share resources and not just look at common information. Of the 25 interactions, a group member moved in 14 of them in order to share resources. In contrast, someone moved in only four of the look only interactions in order to look at another's screen, even though there were almost the same number of these interaction types, as shown in Figure 8. Five of these 25 interactions involved physically moving back and forth between two or more resources in order to see various aspects of the work in question. In these live interactions, participants might have benefited if they were able to have all the

No resources used

26%

Look only

13%

Mouse/keyboard used 49%

Figure 9: Resource usage by non-owner in all interactions as a percentage of time.

4The time values for events were calculated using the recorder-generated time-stamp on the video.

1 6

information on their respective screens and be able to share it. Figure 1 0 gives a summary of physical movements of the team members in order to use resources. That team members would move, sometimes multiple times, in order to use each other's resources, is indicative of the importance placed on having a common work space that the participating group members could share.

Another interesting questions is whose resources are used when an interaction happens. Figure 11 gives a description of the interactions from this view. In a little over half the interactions, the owner of the resource was the initiator of the contact. In roughly one third of the interactions, the initiator was not the owner. This says that in a number of interactions (here, about one third), someone initiates a contact with another team member and then uses that team member's resources for the work. One possible reason for this is that each group member has the keyboard and screen configuration set to their preferred settings, making it difficult for others to use the terminal. If the recipient is providing information to the initiator, she may be more comfortable using her own terminal for the work. If the initiator is requesting coding help, the recipient may find it easier to work from the initiator's terminal than try to recreate the situation on her own terminal. Thus, the choice of whose resources to use may be situation dependent; a system to support collaborative work may need to consider both situations. For the remaining 14% of the interactions, either a common resource, such as the whiteboard or pencil and paper, was used or multiple resources from multiple owners were used. The common resources provided more space and the ability to do free hand work that is easily altered, and all participants can work at the same time. Multiple resources were used mainly to compare work and ideas or to make a modified copy of an existing small piece of code. These functions are also important in any system designed to support collaborative work.

Interaction Types

The group had several types of interactions which varied in content, purpose, and means of interacting. Different types of interactions were used to accomplish different goals; group members used whichever type of interaction that seemed appropriate. The preferred type shifted over time as the needs of the group changed during the course of the project. During the initial orientation phase, group members spent most of their interaction time in meetings to help each other understand the new tool kit and programming language. As the team shifted into the working phase, meetings became less frequent while more spontaneous small group interactions became more frequent. Group members spent more time working on individual tasks and shifted towards less planned interactions.

These interactions can be divided into categories based on the type of communication. For this division, I distinguish synchronous communication, in which members interact in real-time, from asynchronous communication, in which members do not interact in real-time. I also distinguish scheduled interactions, where the time for the interaction is communicated ahead of time, from unscheduled interactions ("spontaneous"), where the interaction occurs with no advanced agreement about the time.

This division gives four types of interactions, as shown in Figure 12. Formal interactions are synchronous, scheduled periods for work. For this group, formal interactions consisted mainly of scheduled group meetings, but this category could also include other kinds of meetings or planned work sessions. Informal interactions include all synchronous, unscheduled (spontaneous) interactions. This could range from quick exchanges up to unscheduled meetings. This category will be broken down further later in this section. E-mail interactions (asynchronous) were less common for this group, probably due to our physical proximity. The last category is for work that is passed serially from one member to the next; in this type, one person leaves something for

1 7

Level of Use

Look Only

Moved once 3

Moved back and forth 1

4

Look/Point

6

1

7

Look/Point/ Type/Mouse

11

3

14

Total

20

5

25

Figure 10: Physical movement in order to use specific resources.

Initiated as:

Total

Initiator is same as owner 25 4 4 33

Initiator is not same as owner 15 6 1 22

Common resource used 2 2 4

Multiple resources used 4 1 5

46 13 5 64

Figure 11 : Resource ownership in interactions

1 8

Synchronous Asynchronous

Formal Scheduled lnt eract ions "Drop Off"

Informal E-mail Unscheduled lnt eract ions Communications

Figure 12: Types of interactions

another to pick up at a specified time. This sort of interaction occasionally occurred, especially when interacting with other development groups in the lab who were depending on particular pieces of work to be completed; however, there were no interactions of this type observed among the group members. (This category could potentially include all the individual work done by the members, depending upon how the definition is used; however, this information can only be determined by the absence of interactions within the group.)

The first three of these types of interactions -- formal, informal, and e-mail -- are discussed in detail below. The discussion will focus on the informal interactions of the group, as these are the most interesting for designing collaborative systems.

Formal Interactions

The group had relatively few formal (synchronous and scheduled) interactions. During the first three weeks, the group met almost daily to share information on the new tools and language being used. Once the initial orientation period was over, the meetings became less frequent, usually once a week. A total of seven meetings were called during the nine week "real work" period. Scheduled meetings were of two types: administrative and technical. Administrative meetings generally were for status reports and scheduling. Technical meetings were called either to solve a problem that required all members' input or to present technical information that was complex and needed by the whole group. Simple technical information was usually sent by e-mail, while complex information needed only by a few members was conveyed outside of meetings.

A breakdown of the meetings and their purpose is given in Figure 13. Meetings have been classified by their primary purpose, as all meetings had elements of both. The majority of meetings were administrative and were generally called by the leader. Usually, we each gave a quick status report and brought up any problems that required the whole group's input to solve. We then discussed any scheduling problems or foreseen

1 9

Meeting Week Called by Where held How called Purpose

A 7 Leader Meeting area e-mail Administrative

B 8 Leader Meeting area verbal Adm inistr ativ e

c 8 TechnicaGuru Meeting area verbal Technical

D 9 Leader Meeting area verbal Administrative

E 11 Leader Meeting area verbal Administrative

F 12 Leader Meeting area verbal Adm i nistr ativ e

G 12 Leader Work area verbal Technical

Figure 13: Meetings held within the group.

schedule slips. These meetings could take anywhere from an half an hour to three hours, depending upon the issues raised; longer meetings generally had more technical content. Meeting notice was usually given verbally, with a request to have a meeting at a specified time. Technical meetings were called on shorter notice and were concerned with a specific issue. Meetings were held in the meeting area of the lab (see Figure 1 for the layout of the lab) except for meeting G, which was held in the work area in order to use a workstation for demonstrating.

E-mail

The group's use of e-mail was small. It was primarily used to communicate technical information, make a request for project-related information, or communicate about a meeting. Since group members generally worked in the same room for a large part of the day, most other communications were handled verbally. Still, the group made use of e-mail for some of its communications, indicating that it filled a need not filled by the other communication methods.

All mailings made within the group were clearly project-related in purpose (of the category technical , as used in the previous sections); no mailings were made for social or non-technical reasons within the group.s The total number of mailings made to the entire group during the three-month period was 28; group members received

5Mailings to a group member from someone outside the group were not recorded, though they were often brought into group discussions. One such personal mailing prompted much non-technical discussion within the group. The mail contained a scientific "brain-teaser" that many group members discussed. Other personal mail shared within the group included replies about technical problems posted to newsgroups and such.

20

individual mail of which I did not keep count. This averages roughly one piece of mail to the group every two days. Figure 14 shows the different categories of mail that were sent. The first purpose, information/how-to, covers mail sent to provide specific technical information to all group members. The information sent was usually too complicated to give verbally. This group included directions for running new tools, detailed information about specific portions of the code, announcements of updates to code, or compilations of information gotten from other sources. This was by far the largest category of mail, comprising 79% of the group mail sent. The next category, request/question, includes all requests for information or actions by others and specific questions addressed to the group. This included questions about where to find information or requests for specific information that was not needed immediately. This category comprised roughly 14% of the mailings. The last category, meeting scheduling, included notices of meetings and requests for scheduling a meeting. This was the remaining 7% of the e-mail. This mail occurred at the middle of the work period, when a special meeting was called.

Group mail

Total

From leader

From socio-emotive leader

From system coordinator

From historian

Information/ how-to

22

74

7

7

0

Request/ question

4

7

0

7

2

Meeting scheduling

2

7

0

7

0

Figure 14: Mail sent to entire group.

Total

28

76

7

3

2

Over half of the mail (57%) was sent by the group leader. This is particularly true of the technical mail, of which 63% was sent by the leader. The socio-emotive leader sent almost all the rest of the technical e-mail. Surprisingly, the technical guru sent none of the technical e-mail; her preferred way of interacting seemed to be one-to-one. The information/how-to mail was more spread out, with a smaller proportion coming from the leader. The other three group members did not send any group e-mail, although they may have sent personal mail that was not recorded.

2 1

Informal Interaction

This category constitutes the bulk of the interactions that occurred in the group. Our time was primarily spent in the same room, working on individual tasks. The group was very open about both work and social communications. Group members felt free to walk over and look at what another person was doing, offer unsolicited advice on a problem, or join in any discussion taking place within the group. The general information presented in this section is based on the entire three month observation period. . The specific findings given in the following sections are based on analysis of the twelve-hours of video tape. The informal interactions recorded on videotape are of the same type and mix of those recorded in my notes; there were no formal interactions during the two days of taping, so the recording captured only informal interactions.

Purposes of communication

Communications were frequent and served many purposes. The categories I have used for my observations are technical, non-technical, duty, looking, and unknown. These categories are the same as those used in previous sections, except the other category has been further divided in to duty, looking, and unknown. Technical interactions occurred for project related reasons. Examples of these include requests for information or help, voluntary communications of new information or ideas, announcements of completed tasks, scheduling discussions, or discussions of project-related issues. The non-technical interactions consisted of social and recreational communications, joking comments, or plain goofing off. These often occurred while waiting for a compilation to complete or during other time that could not be used to make project-related progress. Interactions classified as duty consist of communications necessary to the function of the group but not really technical or non-technical in nature. In this group, it was mainly answering phone calls and calling the requested person; however, other groups might have interactions such as roll call or status reports that would be considered duty. Looking is a non-verbal interaction where one person looks at either another person or their work for a period of several seconds. This happened frequently in our group and was often a prelude to unsolicited help or advice, although infrequently it was the total interaction. The interactions categorized under unknown had too little information available for me to make a reliable categorization. Most of these were short, isolated verbal interactions of an ambiguous nature.

A small portion, roughly 10%, of the interactions had more than one purpose. All identifiable purposes that occurred during the interaction were recorded. For our group, this mainly consisted of shifts between technical and non-technical content. For analysis, I have counted any interaction with technical content as a technical interaction for two reasons. First, the majority of the time spent in these shifting interactions is technical, with only one interaction being the exception. Most communications had a clear differentiation between the technical and non-technical content, making the time spent on each easy to calculate. Second, most of the shifting interactions were initiated for technical purposes then shifted to non-technical; this was the case for roughly 80% of the interactions in this group. More detailed information is given in a later section.

Methods of communication

The interactions happened in various ways within the physical setting. These can be divided into five primary types: call-over, broadcast, wheel-over, look, and gather; an adjunct type, join, is also used. A call-over consists of one person (the initiator) addressing another person (the recipient) directly without moving to where the recipient is. These could range from quick questions to extended discussions, with the

22

key features being the direct address of the recipient and the lack of movement. A broadcast is similar to a call-over, except the group as a whole is addressed. These could be prefaced with an indicator, such as "Hey, everybody ... " or "Does anybody know if .. ", but were not always, such as the loud comment "Prado [a computer] is down again". Not everyone responded to any particular broadcast, but very few broadcasts went completely unanswered. A wheel-over is an interaction in which one of the parties moves to where the other party is. Since we were all sitting in rolling office chairs, we generally wheeled over to where the other was if we needed to be near each other. Occasionally someone would walk over to another, especially if that person were one of the geographically remote members. I have classed walking over with wheeling over for this analysis, since the end result is the same. A look involves one person, the initiator, looking at another person or the work. There is no verbal interactions in this case, only looking. A join occurs when an additional member, other than the initiator or recipient of the interaction, becomes part of the discussion between the initiator and the recipient. A join means that three or more people are involved; there must be an initiator and a recipient, plus one or more members who join an interaction. A gather is an interaction in which at least three people simultaneously come together to begin an interaction. This is similar to a broadcast in many ways, but in a gather, people physically come together. This can happen as a result of a broadcast asking people to come together or as the result of an unusual or interesting event.

On occasions, the group would have a spontaneous meeting to discuss a technical issue that affected all the group. These were called most often by the leader but were also called by other members of the group. A broadcast was made and groups members gathered in the center of the U, often using the whiteboard during the discussion. The meetings were generally short and for a specific purpose. Other times, a non-technical gathering would occur, especially when a file server crashed and no one was able to work. Some joins turned into gathers when several members joined a wheel-over by wheeling over themselves. (These are recorded as several joins that ended up as a gather to distinguish them from a specifically called gather.)

In recording the method of interactions for analysis, the interactions are classed by the actions of the initiator, but a record is kept if a change happens. For example, if the initiator calls-over to the recipient, the event is classed as a call-over. If the recipient then wheels over to the initiator, a note is made of this. This type of change occurred in roughly 16% of the interactions, a majority of which involved sharing resources; one of the participants needed to move to where a shared resource was located in order to continue the interaction.

Purpose and method in use

The interactions can be divided into the purpose categories (technical, non-technical, duty, looking, and unknown) and the primary categories for the method of interaction (call-over, wheel-over, broadcast, look, gather, and join) discussed in the previous section. Figure 15 shows the number of interactions initiated in each purpose and method category. Some categories had no interactions of that type (ex. a gather for duty purposes) and some are impossible combinations (ex. a look initiated by a call-over).

From this figure, we can see that the most prevalent purpose for interactions was technical, with 90 out of the 144 interactions in this purpose category. Most interactions were initiated by calling over to the recipient, as shown in the call-over row, with 79 interactions that used this method. As would be expected, the greatest number of interactions were technical call-overs; this is followed by technical wheel-overs, then non-technical call-overs. Broadcasts were used much less frequently and were about equally divided between the technical and non-technical columns. The category Look-Looking at first seems odd, but the four events in this group were

23

Inter initia

Purpose· .

action ted as:

Call-over

Wheel-over

Broadcast

Gather

Look

at ion • c,'~> ~ ·~0; 0 ~ ;-.0 ,6 0' ~ "'*"~ Total by initi

"-.ru ..;;;.o

Technical

62.5%

Non-Technical

27%

Unknown 3%

Duty 3.5%

Looking 4%

Figure 16: Percentage of interactions by initiation purpose

work then commenting on something interesting; this category represents only the looking events that did not result in anything interesting for the looker. This type of interaction cannot be dismissed when considering what a collaborative system might need to support.

Figure 1 7 shows the proportion of interactions that were initiated by each method. As mentioned above, over half the interactions were initiated as call-overs. Wheel-overs were used to initiate over a quarter of the interactions. These two methods were the main way this group interacted; however, it is important to note that broadcasts and gathers, which are addressed to multiple group members, were used in 1 5% of the interactions. This argues for supporting some means of addressing multiple group members within a collaborative system. Looking was the sole means of interaction in 4% of the events. As stated above, this does not include the interactions that progressed from looking to verbal interaction; therefore, this number does not reflect the true importance of looking for the group's interactions.

In a join, another group member began participating verbally in the interactions at some point after the interaction began. A join occurred in almost 20% of the interactions. Sometimes the joiner just called over without physically moving to where the interactions was occuring. Other times the joiner did move, often to see a resource that was the focus of the interaction. Joiners were usually not explicitly invited to join an interaction; most joiners decided to join after overhearing parts of the on-going interaction. The majority of joins occurred when the interaction was a call-over. People tended not to join on an interaction initiated as a wheel over. The method of initiation may have been an indicator whether or not joining would be welcome, but I cannot say conclusively. Group members joined an interaction to various degrees; some joiners participated for the duration of the interaction, while and others only interjected a brief comment. Many times, group members actively listened to interactions but did not join in.

25

Some joins ended up with most of the group members together as a gather, though not all gathers were initiated as such. Some were called as a gather in order to discuss a

Wheel-over

27% Call-over

54%

Broadcast

14%

4%

Figure 17: Percentage of interactions by Initiation Method

problem. Some ended up as a gather after a number of the group members gradually joined an interaction. A different sort of gather occurred in serial, generally around an attraction. In these, group members floated in and out of an interaction. At any one time, only three or four group members might be interacting, but at some point all group members had joined in the interactions. This type of interaction will be discussed in more detail in a separate paper

Of the 144 total interactions, 15, or roughly 1 0%, changed purpose during the interaction. That is to say, about 90% of the interactions served only one purpose and · did not have multiple purposes. The changed happened only between technical and non-technical, with twelve interactions moving from technical to non-technical purpose and three moving from non-technical to technical. The total times for these are given in Figure 1 8. Four of these also changed method as discussed below. The number of initial purpose (technical or non-technical) that changed is proportional to their number overall and to the amount of time spent in each category. I can't say why these interactions changed. Much of it seemed to be the natural flow of conversation within the group.

By definition, only a call-over and a broadcast can change method. A wheel-over is counted as such even if the participants separate and continue, which was rare; a gather is treated similarly. A true look involves only looking, usually just for a small number of seconds; it was counted as another type of interaction if the method changed. Figure 19 shows the number of interactions which changed methods after the interaction began. These are divided by those that involved resources such as a terminal screen or whiteboard (resources are discussed in a prior section) and those that do not. Interactions which involve resources usually necessitate the interacting parties be together; this would account for the changes that involved resources (82%). The others changed for unknown reasons.

26

From Figure 19 , we can see that 23 interactions began as call-overs. Of these, 22 of these turned into wheel-overs, with the other turning into a gather. Five interactions began as broadcast and then turned into wheel-overs or gathers. As

Change frorn/to Number

Technical to 12 non-technical

Non-technical to technical 3

1 5

Figure 18: Interactions in which purpose changed

27

Purpose: Total

No resources used: 1 4 5

Call over to Wheel over 1 3 4

Broadcast to Wheel over 1 1

Resources used: 17 6 23

Call over to Wheel over 15 3 18

Broadcast to Wheel over 1 1

Call over to Gather 1 1

Broadcast to Gather 1 2 3

18 10 28

Figure 19: Interactions in which the method changed

discussed in the previous section on resource usage, the use of a resource was important enough to warrant one person moving to where the other was; of the 28 total that changed, 23 involved resources. (In 14 interactions that involved resources, the two people were already seated next to each other, so a call over was enough to begin sharing the resource.) The representation of call-overs and broadcasts are proportional to the number of these interactions total.

Individual differences

Group members used the full range of interactions methods; however, there were marked differences in proportions among the members, with many group members having a preferred method of interaction. The leader and socio-emotive leader used broadcasts more often than the other group members -- 13 and 7 times respectively, with one or none for the other members -- and the socio-emotive leader called the one gather. The responders to any particular broadcast tended to be those who were in the U, not the geographically remote members. (I assume that at least the remote member seated in the lab heard the broadcast, as this group member did respond on a few occasions.) The technical guru often used a look to check on what other group members were doing. This seemed to be this member's preferred method of keeping up with the work of the other members. Sometimes the look was followed by advice or pointers to information; other times it was merely a look. The leader and tool builder tended to use more call-overs than any other method of interaction, whereas the problem consultant and the system coordinator primarily used wheel-overs to initiate interactions. This is

28

not surprising given the latter two are the geographically remote members and the leader and tool builder were inside the U.

Some of the differences in interaction methods among group members may have been due to group members' native languages. As stated before, this group had roughly half the members sharing one native language and half another. The common language for work was English but not all group members were equally comfortable with it. For some interactions, group members who did not speak a common native language may have preferred to be closer to each other, and therefore used wheel-overs more often, in order to point to the screen or use other artifacts to clarify the discussion.

Time

In order to understand the interactions, we also need to look at the time value for the interactions. Time can be considered in several ways. If we count each of the interactions once, regardless of the number of participants, we get the clock-time consumed by the interaction. This is the view of time that was used in the above sections. It is the actual amount of time during which the interaction was taking place. Figure 20 shows the clock time for each category of purpose and method discussed above. The total clock time of 339 minutes 55 seconds for the videotaped interactions is 47% of the total recording time; thus, some form of interaction was occurring almost one half of the time group members were together. The proportion of clock time spent for each group corresponds roughly to the proportion of these events in the event counts given in Figure 15. For instance, the technical call-overs make up 35% of the event count and take 31% of the clock time for interactions, and technical wheel-overs constitute 19% of the events and consume 24% of the clock time. Non-technical call-overs are 16% of the events and use 24% of the clock time. Technical broadcasts are 7% of the events and 9% of the clock time. Thus, no one type of interaction purpose and method uses an extremely large amount of clock time in comparison to the number of events of its type.

There are a number of alternative ways of looking at the time spent in interactions. These include the person-time of any interaction (the clock time

29

Purpose·

Inter initia

action ted as:

Call-over

Wheel-over

Broadcast

Gather

Look

on ·v~ ():' . "'0;, 0 ~ ~e;

~,c., 2f *

fill in to a satisfactory degree. Members shared information as it was obtained, so that all group members had, more or less, the same knowledge base upon which to draw. A system that isolates information into separate areas would not effectively support this group's way of sharing knowledge.

Interactions are an important part of the work that the group did. The total clock time spent in interactions (339 minutes 55 seconds) is 47% of the total video recording time, indicating that some form of interaction was occurring almost one half of the time. Interaction happens often. This is different than the stereotypical model of the lone programmer who only talks to others in order to put completed sections of code together.

A number of interactions had multiple recipients and many had other group members join in the interaction. The average number of participants in an interaction was 2.4. Systems that only join two people together may not be adequate to support the types of interactions that users will want. Judging from the data gathered, users may want to address multiple people at one time, everyone at one time, or several people serially. Other group members may want to be able to monitor general conversations within the group, in order to join in the relevant ones. Joining, as discussed previously, was important to the way the group functioned. Group members monitored conversations and joined if they had a contribution. This means that a collaborative system, in order to mimic this very human way of interacting, needs to provide a monitor function and a joining function.

Initiators don't always know how the interaction will turn out. The interaction may change to include more people, share objects, and such. Interactions were often joined, call-overs or broadcasts turned into wheel-overs, and other changes happened. Some joins turned into gathers when several members joined a wheel-over by wheeling over themselves. This type of change occurred in 23 out of 144, or 16% or the interactions. Eighteen of the 23 involved resources that needed to be shared. All of the changes on video tape were from a call-over or a broadcast to a wheel-over or to a gather, and generally the movement happened in order to look at another's screen or to have a prolonged discussion.

"Just looking" is important to the group. The category Look-Looking, as used in some of the charts, at first seems odd. These events in this group seemed to be someone looking at another's screen just for the purpose of looking, though I can't say why it occurred (to satisfy curiosity? to fill time? because it was there?). A collaborative system might need to provide a "looking" function, so group members can look just to see what is going on. Some looking events, events in the Look-Technical category, involved the initiator, or looker, pointing to the recipients screen, indicating something particular. These provide information without a prolonged interaction.

Joining on-going interactions was important to the way the group functioned. I cannot say with certainty that joining was not a disturbance to some, but all group members joined others on occasions and were joined themselves. The practice of joining was certainly entrenched as a means of interacting. From the context of the discussions and from the three months of observations, I feel that joining was not seen primarily as a disturbance. The group welcomed others who joined in conversations, and encouraged contributions from all group members on almost any issue, technical or non-technical.

Another factor to consider for collaborative work is the relatively low percentage (15%) of interactions that were initiated as either broadcasts or gathers. Given the large percentage of time spent in multiple person interactions, the group seemed to have few discussions that began as group discussion. The group members mainly joined in as they saw fit, contributing to discussions that were overheard if they had a contribution to make. Group members tended to monitor any conversation that occurred in the work area and ignored those that were irrelevant to them. At the start of an interactions, group members didn't know how many group members and which would have input in the conversation. Only a small percentage were initiated as group discussions, yet a large proportion involved others joining in a discussion. Some of these eventually involved all

3 1

group members, while others only involved one or two. The unpredictability of the participants would make a system that did not allow late-comers highly awkward for this group to use.

As shown in Figures 5 and 6, the geographically remote group members were relatively isolated in group interactions. The system coordinator and the problem consultant did not work in the small U-shaped group of terminals. One of these group members sat somewhat removed from the group but in the same room, and the other sat in an office on the same floor. Even at a small distance the rate of interaction drops off severely. This seating arrangement was self-selected, so one cannot draw firm conclusions from it, but geographically remote members did differ in the number of interactions, how interactions were initiated, and the type of interactions they were involved in. A collaborative system should try to make all members feel as if they were physically near each other and not as if they were geographically remote in order to promote easy interactions.

Summary and conclusion

This paper addresses the general group interactions of a software development team. By taking a high level look at the interactions of this group, we can make some conclusions about type of work a computer-based collaborative system would need to support.

Group members interacted with each other for a number of reasons. Sharing information, asking for help and building social bonds were among the most prevalent. Some of these interactions required the use of resources such as the computer screen or the whiteboard. Most interactions were spontaneous, initiated to meet the needs of the moment; however, some interactions were planned in advance to meet an on-going need.

The group members interacted in a number of different ways, ranging from face-to-face meetings to e-mail to informal interactions during the work day. Each of these interaction types supported a different communication need of the group. The face-to-face meetings brought the entire group together to discuss issues and resolve them, and e-mail was used to schedule meetings and distribute information to the group. Informal interactions occurred sporadically throughout the work day; these interactions were used to handle communications among a subset of the group. Informal interactions formed the bulk of the groups communications and occurred many times during the working day. Members spent a significant portion of their time interacting with each other.

From results of observing the working patterns of this group, we can see that a computer-based collaborative system would need to support a wide range of interaction types and be very flexible in its use. Some interactions were planned in advance but most were not; spontaneous interactions must be possible and easy. Many interactions started with two people then grew as others joined; allowing others to listen in and join an interactions was integral to how this group worked. Many interactions required resources to support them; sharing screens, keyboard and mouse control, and such was an important way for group members to share information and work together.

Many more issues remain to be studied. Other questions that could be addressed concern the one-to-one interactions of the group members and how much time individual group members spent interacting in the different ways. These will be addressed in a later phase of analysis.

Acknowledgements

A number of individuals have contributed significantly to this work. Foremost are the Golab members who graciously allow themselves to be observed in the interests of research. Both Dana Kay Smith and John B. Smith have provided support and feedback

32

during the course of this project. This work was supported by the National Science Foundation (Grant #IRI-9015443) and IBM Corporation (SUR Agreement #866).

33

References

Bales, R.F. (1970). Personality and Interpersonal Behavior. New York: Holt, Rinehart, and Winston.

Lewin, K., Lippett, R., & White, R. (1939). Patterns of aggressive behavior in experimentally created social climates. Journal of Social Psychology, 1939, 10, 271-299.

34