Embed Size (px)
Citation preview
Growing Jelled Teams
Ömer DOĞAN
Informatics Institute, Middle East Technical University, Ankara, Turkey
Abstract. Software projects are complex systems whose success heavily de-
pends on the skills of the project teams. Studies beginning from the late 1960s
show that there may exist 10-fold differences in productivity between different
teams. As these studies reveal, what makes the difference in productivity is
much more sociological rather than technological. In this paper, the things that
managers should do to help forming a jelled development team are discussed.
How managers can remove the impediments that prevent a development team
from jelling is explained. A questionnaire is prepared based on the managerial
issues for the assessment of the productivity of a team. Assessments of individ-
ual developers from different project teams are collected to present how mem-
bers of different teams encounter managerial problems inhibiting formation of a
productive team.
Keywords: Software Team Productivity, Jelled Teams
1 Introduction
Many researches on the success of the software projects show that most of the soft-
ware projects are not successfully completed. The most widely known research on the
success of the software projects, the CHAOS report [1], shows that the amount of
successfully completed software projects is about one third of the failed and chal-
lenged ones.
The success of the software projects are bound to the productivity of the development
teams. In order to increase the amount of successful software projects, the productivi-
ty of the software teams should be increased.
2 Productivity Variations of Teams
Many researches show that there may exist performance differences on the order of
magnitude between different development teams with the same level of experience.
According to the study of Weinberg and Shulman (1974) [2], productivity differ-
ence between the teams was 5-to-1 in program size and 2.6-to-1 in the time re-
quired to complete the same project.
The study of Boehm [3] using 69 projects has shown that the best team was 4 times
as productive as the worst team.
In another notable study [4] on seven identical projects, there was 3.4-to-1 differ-
ence in productivity of the teams. Although the developers in the study were all
experienced programmers who were enrolled in a computer-science graduate pro-
gram, the difference in the productivity of the teams was observed.
According to Lakhanpal (1993) [5], team cohesiveness is the most effective factor in
the productivity of the teams. In the following sections, the factors that affect the
formation of jelled teams for successful software projects are explained. With the
accompanying questionnaire results, each factor is analyzed with two aspects: the
importance of the factor and how often the factor is encountered according to the
participants.
3 Factors preventing formation of jelled teams
The most important indication that a group of people forms a jelled team is that the
members of the team desire to remain in the team. When a team is jelled, members of
the team are more strongly motivated to contribute to the goals of the team.
Managers cannot make the team jelled but only remove the impediments preventing
formation of jelled teams. In the following sections, factors that prevent formation of
jelled teams are discussed. The factors are based on the study of Demarco and Lister.
[6]
3.1 Defensive Management
It is not possible for a project manager of a software project to be expert on all the
subjects that the team is dealing with. The only thing a project manager could do is
forming the right team and trying to make the team productive. A software team will
usually consist of many people each having expertise on different areas. Therefore,
the team members should suggest their ideas on the subjects that they are good at. The
best thing a project manager could do is to listen to the team and trust the team.
This approach does not guarantee that the team will never make mistakes. Manager
should allow the team to make mistakes and also allow them to learn from their expe-
riences. When a team is afraid of failure, they will not take risks and the way to crea-
tivity and innovation is closed for the team.
It is important to continuously evaluate the experiences and lessons learned. An im-
portant practice for continuous improvement is holding regular retrospective meet-
ings. In these meetings which are held with the participation of all the team members,
the team inspects what they did well and what was wrong. They explore better ways
to work more effectively.
According to the questionnaire results, most of the participants think that their opin-
ions are important for the project. The following figure shows the assessments of the
participants.
Most of the participants assess that defensive management is an important factor that
decreases the productivity of a software development team, as shown in the following
figure.
3.2 Bureaucracy and Paperwork
As Scott Ambler states [7], the main goal of software development is to produce a
high-quality system that meets customer’s expectations in a timely manner. Any work
that is not contributing to this goal should be avoided. In the projects that comprehen-
sive documentation is produced, it is usual to end up with outdated and unread docu-
ments which have no benefit on the product.
This type of unnecessary documentation is usually accepted as a waste of time by the
developers. Especially when the documentation becomes more important than devel-
oping the software, developers begin to have a negative attitude to work. This results
in damaging the cohesion of the development team.
According to the questionnaire results, most of the participants think that documenta-
tion is not done at the level that they think it should be. The following figure shows
the assessments of the participants on the amount of documentation.
Most of the participants assess that excessive documentation is an important factor
that decreases the productivity of a software development team, as shown in the fol-
lowing figure.
3.3 Fragmentation of Worker’s Time
The interaction between the team members is an important factor that helps formation
of jelled teams. When a developer is assigned to more than one team, the interactions
of the developer are dispersed and interruptions that the developer encounters highly
increase. This situation does not only prevent formation of a jelled team but also de-
creases the performance of the individual developer.
Being member of a team requires interaction with the team members which results in
many interruptions during a working day. The following figure shows the causes of
interruptions based on a study [8] on the fragmentation of worker’s time. When the
causes of interruptions are analyzed, it is obvious that being member of more than one
team results in a higher amount of interruptions.
The following figure from the same study shows the reasons of interruptions. This
figure also shows that the amount of reasons increases when the membership of more
than one team is assigned to a person.
Results of the questionnaire show that about half of the participants live fragmenta-
tion of time in their projects.
On the other hand, most of the participants think that fragmentation of time is an im-
portant factor that decreases the productivity of a team.
3.4 Unrealistic Deadlines
A tight but not impossible deadline may sometimes be a motivating factor for the
team since a challenge can increase productivity of the team. However, deadlines that
are considered as unachievable by the team dramatically decrease the productivity of
the team. The following figure [9] shows that the motivation sharply decreases after
an amount of high schedule pressure. The result is missed delivery dates, poor quality,
low morale and loss of respect.
According to the results of the questionnaire, the following figure depicts that the
managers of the projects usually set unrealistic deadlines.
The following figure displays the assessment of the participants on the importance of
setting unrealistic deadlines on the team productivity.
3.5 Physical Separation and Poor Communication
Cohesion in a team is one of the most important factors that help jelling. According to
Martin [10], there are two types of cohesion; social cohesion and task cohesion.
Social cohesion is the degree to which group members have satisfactory relationships
and friendships with other members of the group.
Task cohesion is defined as an attraction to the group because of a commitment to the
group task.
For both types of cohesion, team members should have a high degree of communica-
tion. According to Walz et al. (1993) [11], software project success is highly depend-
ent upon knowledge acquisition, information sharing and integration. These factors
are proofs of the importance of communication for the success of a software project.
Communication can be achieved in various ways like e-mail, videoconferencing and
face-to-face. Various researches show that the most effective way of communication
is face-to-face communication which increases both types of cohesion. The following
table shows the results of a research comparing the team productivity, interaction
quality and process satisfaction of videoconferencing and face-to-face communica-
tion. [12]
Team Productivity Interaction Quality Process Satisfaction
Communication Medium Mean Std. dev. Mean Std. dev. Mean Std. dev.
Videoconferencing 8.67 5.44 10.88 2.51 10.42 2.73
Face-to-face 15.50 3.28 12.83 2.06 11.50 1.93
All these studies show that it is not possible for a team to jell if its members are not all
in one place allowing them to work in a highly interactive way. The team should have
its own area that really makes the team members feel the ownership of the area. This
working area should provide sufficient isolation from the rest of the company to allow
the team members freely interact with each other.
According to the results of the questionnaire, participants do not complain much
about the level of communication in the team. Most of the participants are happy with
their working environment. The following figure shows the distribution of the as-
sessments of the participants on communication and working environment.
The following figures display the assessment of the participants on the importance of
communication and working environment on the team productivity.
3.6 Excessive Overtime
There is naturally always a business need and desire for more results in a project
which results in expecting developers to work long hours. A little overtime can in-
crease the productivity for a short period of time, but there should be an upper limit to
keep the overtime hours productive. Overtime is a means that provides productivity
boost only when it is used for a short period of time.
The following figure [9] shows the relationship between hours worked, total output
and developer motivation.
Since motivation of the developer has an important effect on the productivity, the
total output peaks at the same number of hours as developer motivation. After an
amount of overtime, both motivation and total output decrease. The decrease of the
total output is sharper which means more than the output gained by the overtime is
lost by the decrease in productivity.
Excessive overtime results in:
Increased number of defects
Reduced productivity
Increased turnover
Reduced creativity
Reduced time for self-education
Besides these technical side effects of excessive overtime, it also affects the relations
between the team members. Since excessive overtime results in increased stress and
fatigue with disturbed sleep quality, people become more irritable, impatient and easi-
ly frustrated [13]. These moods heavily damage the cohesion of the team and causes
conflicts in the team.
In the study of Akula and Cusick [14] on the effects of overtime and stress on soft-
ware quality, they identified six consequences of fatigue-effected decrease on quality:
Poor quality can redirect teams away from their core project activities.
Quality assurance and development teams may mistrust each other.
Discussions of defects can add to the task pressure and personal stress.
Worst case outcome can result in critical delay of the project.
Blaming others over the defect undermines team spirit.
Teams may spend more time repairing defects than on developing business critical
features.
According to the results of the questionnaire, a very high amount of participants think
that overtime is one of the most important factors that heavily decreases the produc-
tivity of a development team. The following figure shows the assessment of the par-
ticipants on the effect of overtime on team’s productivity.
4 Conclusion
We have seen that most researches agree on the effects of impediments preventing
formation of jelled teams. The results of the accompanying questionnaire are also
mostly aligned with the mentioned researches. What a manager can do to successfully
complete a software project is to remove the impediments and hope the team to jell.
References
1. Standish Group: CHAOS Report (2010)
2. Weinberg, Gerald M., Edward L. Schulman: Goals and Performance in Computer Pro-
gramming (1974)
3. BOEHM, B.: Software Engineering Economics, Prentice-Hall, Englewood Cliffs, New Jer-
sey (1981)
4. Boehm, B.W., Gray, T.E., Seewaldt, T.: Prototyping Vs. Specification: A Multi-Project Ex-
periment, IEEE - Seventh Conference On Software Engineering, Computer Society Press,
Washington (1984)
5. LAKHANPAL, B.: Understanding the Factors Influencing the Performance of Software De-
velopment Groups: An Exploratory Croup-Level Analysis, Information and Software Tech-
nology (1993)
6. Demarco, T., Lister, T.: Peopleware, Productive Projects and Teams (1999)
7. Ambler, W., Scott: Agile/Lean Documentation: Strategies for Agile Software Development
http://www.agilemodelling.com
8. Tetard, Frank: On Fragmentation of Working Time: A Study of Causes and Effects of Work
Interruptions (1999)
9. McConnel, Steve: Rapid Development: Taming Wild Software Schedules (1996)
10. Martin M. G.: Building Team Cohesion PMP, M2 Consulting Group, Ltd. (2004)
11. Walz, D.B., Elam, J.J. and Curtis, B.: Inside a software design team: knowledge acquisition,
sharing, and integration (1993)
12. Andres, P., Hayward: A comparison of face-to-face and virtual software development teams
(2002)
13. Pilcher, J. J., Huffcutt, A. I.: Effects of sleep deprivation on performance: A meta-analysis.
(1996)
14. Akula, B., Cusick, J.: Impact of overtime and stress on software quality (2008)
