Analyzing Software Teams Using

Belbin’s Innovative Plant Role

K. Todd Stevens *
Sallie M. Henry **

* Department of Computer & Information Science

University of Mississippi
University, MS 38677
Phone: 662 / 915-7396
FAX: 662 / 915-5623
todds@cs.olemiss.edu

** Department of Computer Science

Virginia Tech
Blacksburg, VA 24061
Phone: 540 / 231-6931
henry@cs.vt.edu
 Analyzing Software Teams Using
Belbin’s Innovative Plant Role
Biographies
K. Todd Stevens - Dr. Stevens received his B.S. in Computer Science from Ohio
University in Athens, OH. He received his M.S. (1988) and Ph.D. (1998) from Virginia
Tech, Blacksburg, VA. Between both his undergraduate and graduate degrees, Dr.
Stevens worked in industry at AT&T and Wang Labs, inspiring his interest in software
development teams and teamwork. His primary interests lie in the people-oriented facets
of software development. His research interests include teamwork, software engineering,
software psychology, agents, and design patterns. He is currently an Assistant Professor
in the Department of Computer & Information Science at the University of Mississippi.
Dr. Stevens is a member of ACM and IEEE.
Sallie Henry - Dr. Henry received her B.S. in Mathematics and Computer Science from
the University of Wisconsin – LaCrosse. Her M.S. and Ph.D. are in Computer Science
from Iowa State University. She is currently an Associate Professor in the Computer
Science Department at Virginia Tech, Blacksburg, VA. Dr. Henry’s research interests
include software engineering, software product and process metrics, object oriented
metrics, reusability and empirical experimentation. Dr. Henry is a member of IEEE and
ACM.
 Analyzing Software Teams Using
Belbin’s Innovative Plant Role

Abstract

This paper presents a controlled experiment demonstrating the utility of forming teams
based on Belbin’s team roles. The overall research focuses on the utility of Belbin’s roles
in improving team performance. This experiment explores Belbin’s Plants, who add
innovation and new ideas to teams. The results of this experiment show that Plants
improve team performance. The specific conclusion is that the mean time-to-completion
to solve programming problems is smaller for teams consisting of only Plant members.
This empirical evidence is useful in both formation and evaluation of teams, which can be
useful to managers of programmers as well as educators.

Keywords: Team Formation, Empirical Studies, Software Engineering, Roles

1. Introduction
As Brooks says, there is no "silver bullet" [6] to resolve the monumental problems

that software engineers must address in meeting the demands of the current software

market. Improving the performance of software developers is a key issue in today’s

workplace. In the vein of Brooks’ contention, we have an innovative approach to

improving the performance of teams of software developers, namely by forming teams

based on who can work effectively together. Instead of approaching performance issues

on a level of individual personnel performance, we are interested in the overall

performance of teams of programmers. As DeMarco and Lister [10] say, teams can “gel,”

which means the team displays a synergy such that the overall performance of the team is

greater than its individual parts.

The effectiveness of teams can be described in terms of two aspects, performance

and viability [25], which correspond to the dual problems of productivity and turnover

costs [4, 7, 10]. This investigation focuses on the issues of performance. More

specifically, the performance of team effectiveness is measured and compared using

completion times of teams that develop software solutions to problems given to the teams

in a controlled environment. The teams for this study are formed using Belbin’s team

roles, which has been used previously to form effective management teams [1].

1
2. Background and Motivation
This research project began with the following informal observation, “Why is it

that a team of very gifted individual programmers doesn’t necessarily make a great

team?” This led to a non-traditional investigation of the software development process,

similar to some previous work [8, 23, 30]. For example in the 1980s, the realization that

software could not keep pace with hardware improvements “focus(ed) attention on human

factors in the process of system development as well as the performance of the end user

of computer systems” [19]. We approach the performance issue from this type

perspective, drawing from previous work in psychology and management.

2.1 Psychology Background

This research is based upon some psychological concepts that may be uncommon

to those outside of that field, therefore some terms and concepts need to be provided.

First of all, role theory is useful to examine. As a social psychology term, a role is “the

behavior associated with a particular position in a social system” [11]. Further, a social

role “also carries expectations held by others about the behavior that is appropriate for the

occupant of the position” [11]. Role theory “is an interdisciplinary theory in that its

variables are drawn from studies of culture, society, and personality” [21]. Two

important concepts in role theory are functional requisite and role complement, which are

essentially the foundation of Belbin’s work [1] described below. Functional requisites are

“functions that are necessary for the survival or maintenance of a social system” [3]. A

role complement is a set of roles defined for a given context, for example a programming

2
team. These two concepts combine to form the functional requisites that are embodied by

Belbin’s complement of “team roles.” For this investigation, we are interested in whether

Belbin’s team roles can be used to make teams performance better.

2.2 Management Background: Belbin’s Roles

R. Meredith Belbin conducted a series of experiments that established the

foundation of this research. He developed a model of management teams based on a

complement of roles that needs to be present for a management team to be successful.

His investigation began with a simple idea that different types of people interact in

different ways. Through extensive observation and experimentation in controlled

settings, Belbin identified eight team roles based on these observed “types”: Chairman,

Shaper, Plant, Monitor-Evaluator, Resource Investigator, Team Worker, Company

Worker, and Completer-Finisher. His full work is described in [1, 2].

3
Table 2.1: Brief Descriptions of Belbin Roles [1]

Name Symbol Typical Features Positive Qualities Allowable Weaknesses

Chairman CH Calm, self- A capacity for treating and wel- No more than ordinary in
confident, coming all potential contributors on terms of intellect or
controlled their merits and without prejudice. creative ability
Strong sense of objectiveness
Shaper SH Highly strung Drive and a readiness to challenge Proneness to provocation,
inertia, ineffectiveness, irritation and impatience
complacency or self-deception
Plant PL Individualistic, Genius, imagination, intellect, Up in the clouds, inclined
serious-minded, knowledge to disregard practical
unorthodox details or protocol
Resource RI Extroverted, en- A capacity for contacting people Liable to lose interest
Investigator thusiastic, curious, and exploring anything new. An once the initial fascination
communicative ability to respond to challenge has passed
Monitor- ME Sober, Judgement, discretion, hard- Lacks inspiration or the
Evaluator unemotional, headedness ability to motivate others
prudent
Company CW Conservative, Organizing ability, practical Lack of flexibility, un-
Worker dutiful, predictable common sense, hard-working, self- responsiveness to
discipline unproven ideas
Team TW Socially oriented, Ability to respond to people and to Indecisiveness at
Worker mild, sensitive situations, & to promote team spirit moments of crisis
Completer- CF Painstaking, A capacity for follow-through, A tendency to worry
Finisher orderly, con- perfectionism about small things, a
scientious, anxious reluctance to “let go”

Table 2.1 provides a brief description of all of the Belbin roles in terms of their

team role behaviors and personality characteristics. More complete descriptions can be

found in the Appendix.

One of these roles, the Plant, is particularly interesting for this investigation

because its primary characteristic is innovation, which is a key element in software

development. Therefore, this role is used in the controlled experiment described in

4
Section 3. Plant team members advance new approaches and ideas with special attention

to major issues. A Plant is typically introverted, unorthodox, imaginative, and intelligent

but “inclined to disregard practical details or protocols” [1]. The Plants are the

brainchildren who must be nurtured and occasionally drawn back into the real world

because they tend to be absorbed in thought. They are considered one of the intellectual

types in a team. The “Plant” received this label because some innovative individuals

were implanted on some teams in controlled experiments in order to discover how such

members affected teams. These innovation characteristics seem vital to developing

software.

One should note that Belbin’s view of roles is different than the traditional,

functional view described above in Section 2.1. He has shown that team members can be

viewed with respect to their participation as part of the team, i.e., in terms of their team

roles. For any particular team member, her or his role in the traditional, functional sense

might be a typist on a programming team, whereas her or his team role might be to focus

the team on attention-to-detail and meeting deadlines, viz. a Completer-Finisher. The

team role describes how the individual relates to the team and functions for the team, as

opposed to some technical or domain-specific function. We are interested in

investigating how these team roles affect the performance of software development

teams.

As part of his development of the team roles, Belbin also developed an instrument

to measure the roles. The Belbin Self-Perception Inventory [1] consists of a

5
questionnaire with seven sections. The test produces indicators of an individual’s natural

propensity towards filling each role, similar to psychometrics such as the MBTI [18]. For

each of the seven sections, an individual distributes ten points among eight statements,

based on how strongly he or she feels about each statement. Each of the eight statements

corresponds to one of Belbin’s roles. It should be noted that if an individual takes the test

and distributes the points as evenly as possible, each role would have the average of

8.751. Therefore, we consider a score of 9 or less as insignificant, a 10 as weak, an 11 or

higher as significant, and a 20 or higher as very significant. In other words, when

forming teams based on these roles, a member would need at least an 11 for a given role,

in order to have that role filled.

1
8.75 = (7 sections * 10 points/section) / 8 roles

6
Table 2.2: Sample Section of Questionnaire for Belbin Roles [1]

Section 2: If I have a possible shortcoming in teamwork, it could be that:

____1. I am not at ease unless meetings are well structured and controlled and generally
well conducted.

____2. I am inclined to be too generous towards others who have a valid viewpoint that
has not been given proper airing.

____3. I have a tendency to talk too much once the group gets on to new ideas.

____4. My objective outlook makes it difficult for me to join in readily and

enthusiastically with colleagues.

____5. I am sometimes seen as forceful and authoritarian if there is a need to get

something done.

____6. I find it difficult to lead from the front, perhaps because I am over-responsive to
group atmosphere.

____7. I am apt to get caught up in ideas that occur to me and so lose track of what is
happening.

____8. My colleagues tend to see me as worrying unnecessarily over detail and the
possibility that things may go wrong.

2.3 Using Student Programming Teams

Another concern in conducting this research is that it involves human subjects

participating in controlled experiments. For this investigation, we used collegiate

computer science majors in a senior-year software engineering class. These students are

typically among the top of their class and highly motivated. Most of them had had part-

time employment, internships, and/or summer professional programming experience

during their college careers.

7
 Some previous studies have examined how to form programming teams

consisting of students at various experience levels. For example, Henry evaluates

methods to set up programming teams for software engineering classes [12]. She

presents a heuristic for establishing teams that is based on amount of free time, schedule

conflicts, and grade point average. Scott and Cross also discuss issues in setting up

student programming teams in an effort to make them relatively equivalent [22]. Some of

the issues that they present are academic performance (grades), team and project size, and

psychological profiles including the MBTI. Unfortunately, their treatment is superficial;

they only consider psychological issues such as a team needing an introvert and an

extrovert because their class requires written and oral presentations. “Clearly,” they

conclude, “an Extrovert will be more comfortable with an oral presentation, while an

Introvert may produce a better written report” [22].

Finally, the issue of using student programmers in experiments introduces the

concern that such research does not directly apply to industry programmers. In addition

to the high quality of the participants of this work, Holt, et al. provides support for using

students in studies. They demonstrate that advanced students and professional

programmers are statistically similar in terms of comparing their mental representation

and various performance measures [14].

2.4 Previous Software Development Team Research

Numerous studies have been conducted on software development teams in general

[5, 15, 17, 23, 24, 26, 27, 28, 29, 31, 32]. One investigation by Thomsett is of particular

8
interest for this experiment since it applies Belbin’s roles to software developers [26].

His study presents a qualitative analysis of software teams in Australia using various

measurement instruments, including the MBTI and the Belbin Self-Perception Inventory.

Thomsett reports some impressive, albeit qualitative, results. One company

participating in the study showed “immediate productivity increases of 200 percent,

reported by the senior management of the computing group” [26]. Also, Thomsett

describes some intuitive reasons for the uncommon data distributions of the Belbin roles

and MBTI types: a ‘cloning’ effect. This effect means that managers hire employees

who are similar to themselves because ‘clearly’ they themselves (the managers) are good

employees, and therefore, they should hire other people like themselves. Further, he

observes that “at best, because of the relative lack of Team Worker … and effective

Chairpersons …, computing teams and managers generally lack the required interpersonal

skills,” [26] thus making the teams less effective than they could be.

Unfortunately, there are deficiencies with this investigation: the analysis is

qualitative and the conclusions are not substantiated quantitatively at all. Therefore,

Thomsett presents an interesting study with some initial findings that need further

investigation. He presents general information that appears very useful but has only

intuitive supporting arguments and no empirical evidence. Quantitative analysis needs to

be performed on objective data in order to support his ideas. Such quantitative analysis

and empirical support are exactly the focus of this work.

9
3. A Controlled Experiment on Innovation on Teams
This paper describes a single experiment that is part of a larger research

investigation. The fundamental issue that the overall research addresses is how to

improve the effectiveness of software development teams by using various attributes

including some taken from role theory and personality characteristics. This includes

analyzing extant teams and forming new teams. This phase of the project consists of a

controlled experiment to test the importance of Belbin’s Plant role to software

development team performance.

Curtis has shown that the initial phase of software development consists of

developing potential solutions to a problem [9]. The innovation necessary in this phase is

obvious, and the natural propensity to innovate is the key characteristic of a Plant.

Therefore, members who score significantly high on the Self-perception Inventory for the

Plant role should be an important component of a software development team.

The performance of the teams is the aspect of effectiveness that is examined in

this experiment. For a quantitative analysis, some objective measure of performance

needs to be used to provide a “measure of success.” The performance measure used here

is the time-to-completion for correct solutions. All of the teams were given the same

software problem to solve, and teams that completed a correct solution the quickest were

considered better. The teams were formed such that some were anticipated to perform

well, and other teams were anticipated to perform poorly. After all of the teams finish,

10
the completion-time data was analyzed by comparing the mean completion time of all of

the “good” teams to the mean completion time of all of the “bad” teams.

It could certainly be argued that time-to-completion is a overly simple measure of

success, but this measure was used because it is objective, quantitative, and easy to

collect. A solution was not accepted until it was correct, so that each team submitted

solutions until they got it right, and no subjective quality measure was gathered. Thus,

this experiment demonstrates that teams containing the specified role(s) perform better,

i.e. faster, than teams that do not possess that role(s). Specific details on conducting the

experiments is addressed later in Section 3.2.

The specific purpose of these experiments is to produce empirical results

supporting Thomsett’s results [26]. Several hypotheses were proposed to focus the

research on issues that could be directly tested. The hypothesis that was ultimately

selected investigates the importance of Plants on a team. Specifically, the null and

alternate hypotheses for statistical testing are:

H0: Teams containing all innovative members, i.e. Plants, perform

equivalently to teams with one such member
H1: Teams containing all innovative members, i.e. Plants, do not
perform equivalently to teams with one such member

3.1 Establishing Teams and Groups

To understand how this experiment was performed, the terms team and group

must be defined within the context of this work. Teams are the three-member unit under

investigation. Each team is classified as belonging to one of three groups: All Plants,

11
Some Plants, or No Plants. These group names indicate the number of Plants on each

individual team. Each team in the “All Plants” group has three Plants, whereas each

team in the “No Plants” group has none. Each team in the “Some Plants” group has one

or two members who are Plants.

Using a table similar to Table 3.1 but including all of the teams, the participants

were formed into teams, and the teams were identified as being in a particular group.

Two teams were formed for the successful group, i.e. the teams anticipated to complete

the programming problems quickest. Three teams were formed for each of the other two

groups, with the anticipation that they would perform worse than the successful teams (in

terms of the mean completion times of the groups).

To mitigate any other factors that could influence the teams’ performance, the

other Belbin roles were made as equivalent as possible across the teams, and the team

members’ scholastic grade point average (GPA) was used as a blocking factor. Such

tactics help distinguish the role under scrutiny as the reason the groups perform

differently.

Table 3.1 shows the information used to accomplish the team formation. Rows in

the table contain team member data. For example, “Team X” consists of three team

members, whose data are in the three rows after “Team X.” In each row, the first column

designates the team name. The second column shows member numbers. The subsequent

columns represent the members’ data for the Belbin roles: Chairman (CH), Shaper (SH),

Plant (PL), Resource Investigator (RI), Monitor-Evaluator (ME), Company Worker

12
(CW), Team Worker (TW), and Completer-Finisher (CF). The final column shows the

members’ GPA, which is used to make the teams equivalent, mitigating the chances that

the successful teams simply contained better programmers.

Table 3.1: Example of Data for a Single Team

Team Member CH SH PL RI ME CW TW CF GPA

Team X
1 c1 - - - - W2 - F9 2.9
2 - s2 p0 - m0 - - - 3.1
3 - s0 p7 - m5 w0 - - 3.6

The data in each cell in the table represents that member's score on the Belbin

Self-Perception Inventory. Cells containing a dash (-) indicate that the score was not

significantly high enough to take into account when forming the teams. As described

above, a score of 9 or less is insignificant; a 10 is weak; an 11 or higher is significant;

and a 20 or higher is very significant. Cells not containing a dash contain a letter and a

digit that indicates the team members’ score on the Belbin Self-Perception Inventory.

The letter represents the role, which is also shown by the column headers abbreviations,

and the digit indicates the score on the Belbin test. Scores in the range 10 to 19 are

indicated with a lower case letter for the role, e.g. c1 indicates a Chairman score of 11.

Scores of 20 and above, which are very high scores, are indicated with a capital letter, e.g.

W2 indicates a Company Worker score of 22. This scheme was used because it removes

extraneous information, making comprehensible the large amount of data that was used to

form the teams.

13
 To determine a member’s potential roles even after discarding “insignificant”

scores, several factors were taken into consideration:

1. An individual fills more than one role by having significant scores for multiple
roles, typically two or three roles.
2. Although an individual might have a number that appears to make him or her fill
that role, he or she may not fill that role because he or she has a stronger tendency
to fill other roles. For example, in Table 3.1, member 1 probably does not fill the
Chairman role because the W2 and F9 values are much higher.
3. Other team members may keep an individual from filling a role in the case that the
other member is stronger in the role. This is particularly true if the member has
roles that are significantly stronger. For example, member 3 in Table 3.1 would
not fill the Shaper role because of his or her other stronger roles (p7, m5) as well
as member 2 being such a strong Shaper (s8).
4. Because the scores are relative, not absolute, sometimes a score of ten (10) or
eleven (11) is significant, sometimes not. If a member’s highest scores are 12 in
two roles and 10 in another role, then the 10 would be considered significant,
because the individual has a tendency to assign a few points to all of the
statements in the Belbin Self-Perception Inventory. Member 1 in Table 3.1 is a
good example of when a low score of 11 is not significant; Member 2 is a good
example of when a low score of 10 might be considered significant.

One basic assumption of this research is that some roles can conflict within a

team, such that a team is “better” with only one of that role type on the team. This

appears to be true for certain roles, such as Shaper, where conflicts can occur [13]. As

demonstrated below, other roles appear not to demonstrate this effect; teams with all

Plants perform the best. It is very important to note that the results of this test indicate

individuals who have a natural propensity to these roles. The teams were not formed

based on previous experience or any other factors, and no member was designated as the

leader for each team. Also, the participants had no knowledge of Belbin roles nor of

other qualities that members might possess unless they discussed it amongst themselves.

14
3.2 Conducting the Experiment
The teams and groups were formed prior to the commencement of the

experiments (see Table 3.2), and the participants met in a laboratory where there were

nine computers used in the experiment. The twenty-four (24) student participants had

been formed into eight teams, and each team was limited to one computer apiece. One

computer was used by the experimenter to test and accept problem solutions. Each

participant was given a copy of the problem to be solved that day. Each problem was

intended to be solved in a little over an hour, although some teams ended up requiring up

to two hours. The teams could use any editors, C or C++ compilers, and utilities they

wished. All of the systems were equivalently equipped. Teams emailed their solutions to

the experimenter as soon as they felt that they had a correct solution, and the

experimenter tested the solutions with his own acceptance data, which was not provided

to the participants. A completion time for each team was only recorded once a submitted

solution tested correctly with the acceptance data. Although the problem statements

included some example test data, the participants were informed that they should create

test data themselves in order to have their solution pass all of the acceptance tests.

Table 3.2: Teams Used in the Innovation Experiment

Group Team Member CH SH PL RI ME CW TW CF GPA
1 A
All 1 - s1 P0 r2 - - - - 3.2
Plants 2 - - p3 r0 m1 w4 - - 2.7
3 c0 - p0 - - w0 t4 - 3.4
H
1 - s0 P2 - - - - f5 3.5
2 - s0 p3 - - w1 t6 - 2.6
3 - - p0 - - w4 t3 f0 3.6

15
 Group Team Member CH SH PL RI ME CW TW CF GPA
3 B
No 1 - - - - m1 w1 t8 - 3.0
Plants 2 - - - - M0 W5 T0 - 4.0
3 c0 s2 - r2 m2 - - - 2.6
F
1 - s1 - - m4 - - - 3.0
2 - - - - - w9 t5 - 3.3
3 c3 - - - - W2 - f9 3.1
G
1 - s2 - - - w2 - - 2.7
2 - - - - - w4 - f1 3.4
3 c0 - - - m4 w1 - - 3.4

2 C
Some 1 - s2 - r2 - w0 - - 2.8
Plants 2 - s3 p7 - m3 w0 - - 2.9
3 c4 - - - - w5 t4 f2 3.5
D
1 - s0 p3 - - w4 - - 2.9
2 - s4 p2 - m0 - - - 3.3
3 - s9 - - m3 w3 - - 3.0
E
1 c0 s4 - - - w1 - f2 3.6
2 - - P0 - - w1 - - 3.5
3 - s3 - - m6 w7 - f0 3.0

The experiment consisted of four problems that were solved in four separate lab

sessions. During each of the four sessions, the teams were given one problem to

complete during that lab session. The means of all four problems for each group was

calculated and compared in the following analysis. Having the teams work together on

four different problems acted like replication, strengthening the results by having more

than one data point per team.

The use of one computer per team is an important feature of the experiment. The

intent was to force individuals to work as a team, instead of examining individuals. If the

16
members were allowed to separate and work independently, then the experiment would

simply measure which member on each team could solve the problem first.

3.3 Quantitative Analysis

This experiment provides quantitative results comparing the mean-time-to-

completion performance of software development teams. As shown in Table 3.2, the

teams were formed into groups so that some teams had all members who were Plants

(Group 1, All Plants), some teams had one or two Plant members (Group 2, Some Plants),

and some teams had no members who were Plants (Group 3, No Plants). Teams A and H

form Group 1 (All Plants); Teams C, D, and E form Group 2 (Some Plants); and Teams

B, F, and G form Group 3 (No Plants).

The initial hope was that these three groups would all be statistically different, but

as shown below in the statistical analysis, only two of the groups could be differentiated.

The mean-time-to-completion for the “All Plant” group is statistically different from the

“Some Plants” group, 54.13 and 100.75 minutes, respectively. Further, since the mean of

the completion times for the “All Plant” group is smaller, we can state that the “All Plant”

group performs better. In fact, “All Plant” teams require only 53.73% of the time to

complete the problems as teams with one Plant, on average.

17
 120 100.75
100 86.25
80

Minutes
54.13
60
40
20
0
Some Plants Group1 No Plants Group3 All Plants Group2

Figure 3.1: Comparison of Mean Time to Completion by Group

More formally, this experiment on innovation on a team has a null hypothesis and

attendant alternative hypothesis of:

H0: Teams containing all innovative members, i.e. Plants, perform

equivalently to teams with one such member
H1: Teams containing all innovative members, i.e. Plants, do not
perform equivalently to teams with one such member

An ANOVA using Proc GLM in SAS [16] shows that the groups are statistically

different by F-test (p=0.0412). The means are 100.75, 86.25, and 54.13 for group 2, 3,

and 1 respectively (See Figure 3.1) with standard deviations of 55.81, 56.77, and 26.43

respectively. The R-Squared is 0.5024. This allows the null hypothesis to be rejected,

indicating that the groups are different. Further, Duncan’s New Multiple Range Test [20]

indicates differences among the group means. For two of the groups, “Some Plants” and

“All Plants,” the data shows a significant difference between the groups.

This raises questions about why the “All Plants” group might appear to perform

better than the “Some Plants” group but not statistically better than teams with “No

Plants.” The easiest aspect to question is the size of the sample, in other words the

18
number of teams in the study. We believe that a larger sample size this would remedy

this, with the “No Plants” joining the “Some Plants” group. With a mean of 86.25, the

“No Plants” group is certainly closer to the “Some Plants” group (100.75) than to the “All

Plants” group (54.13). This idea has some statistical support because, when just the data

for the “All Plant” and “No Plants” are analyzed, the groups are different by F-test

(p=0.1011), but this p-value is not statistically different. Thus, although there is a

difference, a statistically significant difference might emerge if a larger number of teams

were analyzed. The difficulty is that finding large numbers of volunteers to participate in

such experiments is difficult. On the “All Plants” teams, all of the members are

innovators; they have a tendency not only to come up with many different ideas but also

to understand others’ ideas more easily. This is an obvious shortcoming of some of the

other teams, as indicated by other team members on a post-experiment questionnaire.

Some subjective observations from the participants, as well as the experimenter

who took notes both during and immediately after each lab session, include positive and

negative perceptions. Notes about the teams predicted to perform well include: “No

negative aspects to this team; everyone worked well together.” “The coordination within

the group worked very well; the work was divided up very well. (Person 1) figured out

the algorithm quickly. (Persons 2 and 3) would quickly produce an initial

implementation. (Person 2) would then type it in incredibly quickly, while (Persons 1 and

3) looked for bugs in the algorithm and made sure that (Person 2) wasn’t making typos.”

All three members of this team identify team coordination and “functional roles” as the

19
key to their success. Some comments from, and about, the “unsuccessful” teams include:

“Motivation wasn’t all that … (sic) present;” the team “couldn’t think of many good

solutions.” The “quiet/reserved team member didn’t participate much,” which is very

unfortunate since this person is a very strong Plant. “Sometimes good ideas were ignored

because they ‘almost had it’ even though the other solution would have been better;”

“We thought in different ways. This made coming up with a single, well-understood, and

good solution next to impossible.” Further comments include “no motivation, no division

of labor” and “some ego problems caused good decisions and ideas from all members to

get tossed out the window.”

4. Conclusions and Continuing Work

This experiment demonstrates the usefulness of forming teams using Belbin’s

roles. It shows that Belbin’s test can be used to identify characteristics of team members

that can be used to make teams perform better.

Obviously, the formal conclusion of this study is the alternate hypothesis stated

above: Teams composed of all Plant team members perform better than teams with some

Plants. Intuitively, it appears obvious that it is good to have innovative members on a

development team; however, controlled experiments are necessary to prove the fact. As

this research continues, more statements that are definitive will be verified. This research

provides guidance to managers in forming successful teams as well as in evaluating

extant teams to identify deficiencies. The intent for evaluating teams would be to rectify

deficiencies and to take full advantage of the positive aspects of the team. It should be

20
noted that this was a limited controlled study. Results may be different for long term

projects simply because human interactions over an extended period tend to be different

than for short-term projects.

As described at the beginning of Section 3, because these conclusions were drawn

from a controlled experiment, other factors can and indeed do affect the performance of

teams. To say otherwise would be ridiculous and misleading. It should also be obvious

that not all development teams can be composed of all Plants, because there are only a

limited number of Plants. Further, teams composed of all Plants are not guaranteed to

perform great because other factors affect team performance; statistically speaking,

teams composed of all Plant members are more likely to perform better. The significance

of this work is that the existence of Plant roles on a team does in fact affect team

performance and can be used as part of the formation of teams. This result should be

used in conjunction with other factors when forming or evaluating teams.

Additional experiments need to be performed on each of the Belbin Roles to

determine which of the other roles are important to software development teams. Some

conclusions about the other Belbin roles have already been reached [13]. Some of the

roles intuitively appear to be less significant than others, for software development teams.

Some of the roles may in fact have a negative impact on a team; some of them may not

have much of an impact because the role is extremely common in the computer science

field. The basic concept that Belbin developed, his complement of roles for management

21
teams, needs to be empirically tested for the computer science domain. Possibly, a

different complement needs to be defined for computer science.

In closing, although some software development managers might use personality

information directly to hire “computer science” types, the literature indicates that team

improvement can be accomplished by combining personality information, such as the

concepts of team roles, with other important factors such as the need to have diverse

teams. The above analysis demonstrates the utility of Belbin’s team roles in forming

teams; evaluating software development teams with this approach is an obvious

extension. Further, if teams are properly formed using roles, then the team members are

happier and more likely to remain with an employer, thus increasing the viability of the

team. All in all, applying Belbin’s role concepts to software development teams can be

used to improve both the performance and the viability of teams and, therefore, team

effectiveness.

22
Bibliography
[1] Belbin, R M, Management Teams, John Wiley & Sons, New York, 1981.

[2] Belbin, R M, Team Roles at Work, Butterworth-Heinemann, Ltd., Oxford, 1993.

[3] Biddle, B J, Role Theory: Expectations, Identities, and Behaviors, Academic Press,
New York, 1979.

[4] Boehm, B W, Software Engineering Economics, Prentice-Hall, Inc., Englewood

Cliffs, New Jersey, 1981.

[5] Bostrom, R P and Kaiser, K M, Personality Differences within Systems Project

Teams: Implications for Designing Solving Centers, in: Proceedings of the

23
[14] Holt, R W, Boehm-Davis, D A, and Schultz, A C, Mental Representations of
Programs for Student and Professional Programmers, in: Empirical Studies of
Programmers: Second Workshop, G M Olson, S Sheppard, and E Soloway, eds.,
Washington, DC, December 7-8, 1987 (Ablex Publishing Corporation, Norwood,
New Jersey, 1987) 33-46.

[15] Jeffery, D R, The Relationship Between Team Size, Experience, and Attitudes and
Software Development Productivity, in: Proceedings of COMPSAC87, Tokyo,
Japan, October 7-9, 1987, (IEEE Computer Society Press, New York, 1987) 2-8.

[16] Littell, R C, Freund, R J, and Spector P C, SAS System for Linear Models, 3rd
Edition, SAS Institute, Inc., Cary, North Carolina, 1991.

[17] Mills, H D, Software Productivity, Little, Brown and Company, Boston, 1983.

[18] Myers, I B, Introduction to Type, Consulting Psychologists Press, Inc., Palo Alto,
California, 1987.

[19] Nichols, J A, “Forward,” in Proceedings of Human Factors in Computer Systems,

March 15-17, 1982, Gaithersburg, Maryland (Association for Computing Machinery
Press, New York, 1982) iii.

[20] Ott, R L, An Introduction to Statistical Methods and Data Analysis, Duxbury Press,
Belmont, California, 1993.

[21] Sarbin, T R, Role Theory, in: Handbook of Social Psychology, Gardner Lindzey,
ed., (Addison-Wesley Publishing Company, Reading, Massachusetts, 1954) 223-
258.

[22] Scott, T J and Cross, J H II, Team Selection Methods For Student Programming
Teams, in: Software Engineering Education: Proceedings of 8th SEI CSEE
Conference, New Orleans, Louisiana, March 29 - April 1, 1995 (Springer-Verlag,
New York, 1995) 295-303.

[23] Shneiderman, B, Software Psychology, Winthrop Publishers, Inc., Cambridge,

Massachusetts, 1980.

[24] Smith, R, What a team!, Management Accounting (October 1993) 48-49.

[25] Sundstrom, E, De Meuse, K P, and Futrell, D, Work Teams, American Psychologist

(February, 1990) 120-133.

[26] Thomsett, R, Effective Project Teams, American Programmer (July/August 1990)

25-35.

24
[27] Trower, J K and Straub, D W, Jr., Improving the Performance of Technologists and
Users on Interdisciplinary Teams: An Analysis of Information Systems Project
Teams, Computer Personnel (November, 1991) 62-72.

[28] von Mayrhauser, A, Task Analysis and the Selection of Software Development
Team Structures, in: Proceedings of COMPSAC84, Chicago, Illinois, November 7-
9, 1984, (IEEE Computer Society Press, New York, 1984) 120-126.

[29] Walz, D B, Elam, J J, Krasner, H, and Curtis, B, A Methodology for Studying

Software Design Teams: An Investigation of Conflict Behaviors in the
Requirements Definition Phase, in: Empirical Studies of Programmers: Second
Workshop, G M Olson, S Sheppard, and E Soloway, eds., Washington, DC,
December 7-8, 1987 (Ablex Publishing Corporation, Norwood, New Jersey, 1987)
83-99.

[30] Weinberg, G M, The Psychology of Computer Programming, Van Nostrand

Reinhold Company, New York, 1971.

[31] White, K B, MIS Project Teams: An Investigation of Cognitive Style Implications,

Management Informaiton Systems Quarterly (June, 1984) 95-101.

[32] Zahniser, R A, Building Software in Groups, American Programmer (July/August

1990) 50-56.

25