Belbin in IT Groups

8/7/2019 Belbin in IT Groups

1/28

Analyzing Software Teams Using

Belbins Innovative Plant Role


2/28



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.

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. Henrys 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.


3/28



This paper presents a controlled experiment demonstrating the utility of forming teams

based on Belbins team roles. The overall research focuses on the utility of Belbins roles

in improving team performance. This experiment explores Belbins 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


4/28

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 todays

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 Belbins team

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


5/28

This research project began with the following informal observation, Why is it

that a team of very gifted individual programmers doesnt necessarily make agreat

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.

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 arefunctional requisite and role complement, which are

essentially the foundation of Belbins 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


6/28

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

Belbins complement of team roles. For this investigation, we are interested in whether

Belbins team roles can be used to make teams performance better.

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].


7/28

Name Symbol Typical Features Positive Qualities Allowable Weaknesses

Chairman CH Calm, self-

confident,controlled

A capacity for treating and wel-

coming all potential contributors ontheir merits and without prejudice.

Strong sense of objectiveness

No more than ordinary in

terms of intellect orcreative ability

Shaper SH Highly strung Drive and a readiness to challenge

inertia, ineffectiveness,

complacency or self-deception

Proneness to provocation,

irritation and impatience

Plant PL Individualistic,

serious-minded,

unorthodox

Genius, imagination, intellect,

knowledge

Up in the clouds, inclined

to disregard practical

details or protocol

Resource

Investigator

RI Extroverted, en-

thusiastic, curious,

communicative

A capacity for contacting people

and exploring anything new. An

ability to respond to challenge

Liable to lose interest

once the initial fascination

has passedMonitor-

Evaluator

ME Sober,

unemotional,

prudent

Judgement, discretion, hard-

headedness

Lacks inspiration or the

ability to motivate others

Company

Worker

CW Conservative,

dutiful, predictable

Organizing ability, practical

common sense, hard-working, self-

discipline

Lack of flexibility, un-

responsiveness to

unproven ideas

Team

Worker

TW Socially oriented,

mild, sensitive

Ability to respond to people and to

situations, & to promote team spirit

Indecisiveness at

moments of crisis

Completer-

Finisher

CF Painstaking,

orderly, con-

scientious, anxious

A capacity for follow-through,

perfectionism

A tendency to worry

about small things, a

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


8/28

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 Belbins 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

. 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

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


9/28

questionnaire with seven sections. The test produces indicators of an individuals 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 Belbins 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


10/28

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 generallywell 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.

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.


11/28

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].

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


12/28

interest for this experiment since it applies Belbins 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.


13/28

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 Belbins 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,


14/28

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 Thomsetts 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,

perform equivalently to teams with one such member

To understand how this experiment was performed, the terms and

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

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


15/28

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


16/28

(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.

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.


17/28

To determine a members 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 multipleroles, typically two or three roles.

2. Although an individual might have a number that appears to make him or her fillthat 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 theother 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) oreleven (11) is significant, sometimes not. If a members 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 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.


18/28

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.

1 A

All 1 - s1 P0 r2 - - - - 3.2

Plants 2 - - p3 r0 m1 w4 - - 2.73 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


19/28

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


20/28

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

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

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.


21/28

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,

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, Duncans 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


22/28

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) wasnt making typos.

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


23/28

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

Motivation wasnt all that (sic) present; the team couldnt think of many good

solutions. The quiet/reserved team member didnt participate much, which is very

unfortunate since this person is a 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.

This experiment demonstrates the usefulness of forming teams using Belbins

roles. It shows that Belbins 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


24/28

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


25/28

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 mightuse 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 Belbins 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 Belbins role concepts to software development teams can be

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

effectiveness.


26/28

[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., EnglewoodCliffs, New Jersey, 1981.

[5]Bostrom, R P and Kaiser, K M, Personality Differences within Systems ProjectTeams: Implications for Designing Solving Centers, in: Proceedings of the


27/28

[14] Holt, R W, Boehm-Davis, D A, and Schultz, A C, Mental Representations ofPrograms 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 andSoftware 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, 3rdEdition, 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 ProgrammingTeams, 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.


28/28

[27] Trower, J K and Straub, D W, Jr., Improving the Performance of Technologists andUsers 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 DevelopmentTeam 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 StudyingSoftware 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 NostrandReinhold 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/August1990) 50-56.

Belbin in IT Groups

Documents

Transcript of Belbin in IT Groups