Broadway, Sydney NS W 2000 email iango Qsyd. dit. csiro.au. Australia. Lawrence Fung, ..... hut thcrc wa simply not enough outstanding work on the project 10.
Proceedings of the 29th Annual Hawaii International
Conference on System Sciences -
1996
Enabling Software Shift Work with Groupware: A Case Study tan Gorton Project Manager, CSlRO Division of lnforma tion Technology, Sydney, NS W Australia, email iango Qsyd. dit. csiro.au
lgor Hawtyszkiewycz, School Of Computing Sciences, University of Technology, Broadway, Sydney NS W 2000 Australia
development of new products[2]. Utilising multiple teams on a software development project enables concurrent engineering methods [3] to be applied to reduce product time-to-market [4]. Each team is allocated a portion of the overall project, allowing the development effort to proceed in parallel. If the tasks each team performs are relatively independent, interteam communication overheads can be kept to a minimum, enabling each team to act autonomously and progress without substantial external hindrance. For teams that are located in different places around the globe, a low level of interdependencewould seem ideal as this reduces the problems and risks associated with long distance communications and information sharing. A further consideration when using globally dispersed teams is the time differences that exist between teams. For example, two co-operating teams located in the United Kingdom and Australia may (depending on the time of year and exact locations) have only a one hour overlap of core working hours. This makes direct communications inconvenient at the least, and potentially introduces a major obstacle for effective team interaction. Significant time differences between development teams do however introduce the possibility of sofhyare shift work Many industries use shift work to provide continuous 24 hour construction of a product. Due to the nature of the products being manufactured (i.e. a new road or a vehicle production line), staff are required to work unsociable hours in the same location to achieve greatly reduced production times. Software systems however differ in nature from most artefacts in that the output of the software production process is a collection of binary files which comprise the documentation, source code and executables [5]. Using data communications networks, these files can be rapidly moved around and shared by teams anywhere in the world. Continuous 24 hour software development could therefore be achieved by exploiting time differences between teams, giving the effect of shift work but allowing teams to work the conventional hours for their location. Time differences
Abstract This paper describes a sojiware development trial which aimed to evaluate the use of a groupware support environment for widely geographically separated so&are development teams. A four person dislocated team working in (simulated) disjoint timezones was assigned a development task to carry out over a two week period. Due to the time and location displacement, the developers were denied almost all opportunities for synchronous communications and had to rely on support from a prototype sofofvare engineering support system developed in Lotus Notes for interactions and coordination. In addition, the tasks in the trial were allocated such that productivity gains could be experienced through positive exploitation of timezone differences, effectively giving around-the-clock working. The paper describes the design and organisation of the trial, reports on the progress of the trial, and presents both quantitative and qualitative results regarding the use of the Notes prototype.
Introduction Many large multinational organisations have numerous software development groups residing in different countries around the world. In most instances each group is primarily responsible for servicing its local and regional market. Occasionally development groups may be seconded to support a project for a remote customer. This is usually achieved by allowing the development team at the customer site to use the remote team as a resource to perform a particular aspect of the project. There are documented examples of complex products being developed by globally distributed teams[l], but these are few and far between, However, the on-going globalisation and downsizing of organisations will necessitate the integration of widely dispersed groups to cooperatively work on the design and
1060-3425/96 $5.00 0 1996 IEEE
Lawrence Fung, Asia Pacific Systems Engineering Centre, BT Australasia Pty Ltd, I Market St, Sydney NSW 2000 Australia
72
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
Proceedings of the 29th Annual Hawaii International
between teams could then be gainfully exploited to give the effect of continuous work on the project, potentially reducing significantly the time-to-market for products The term overnight gain effect has been defined to describe this phenomenon [6]. This project is investigating project control, coordination and communications mechanisms for use in a globally distributed team environments. Teams that operate in such a manner are called virtual teams. We have defined 3 models for organising geographically dispersed groups within virtual teams, namely cooperation, delegation and consultation [6]. We have so far focused on experimenting with the delegation model, and have carried out a small trial between Sydney and Bombay, India, involving detailed design, coding and testing. These activities are more amenable to virtual team structures as by the time they occur, a large amount is (should be!) understood about the problem and its solution, making formal, impersonal procedures and interactions more appropriate [7]. In the delegation model, one group is responsible for designing and developing code modules. Completed modules are then passed to the remote testing group which performs tests from the test specification, and reports the failures observed to the development group. The development group consequently fixes problems and instructs the test group to re-test. Responsibility for overall task completion and monitoring remains with the supervisory development group. To exploit the overnight gain effect, the development group can allocate testing tasks to the test group at the end of their working day. The test group runs as many tests as possible during their day, and hands back the results at the end of their working day to the development group. In this manner, from the development groups perspective, testing has occurred overnight. In order to further evaluate this mode of working, two specific activities have been performed. First, a prototype groupware system for distributed software engineering teams has been developed in Lotus Notes. The need for coordination and collaboration support in software engineering environments has been previously recognised [8], but there has been little penetration of these facilities into commercial CASE environments [9]. Lotus Notes provides inherent support for automated workflow, coordination and replication of distributed databases, and email across multiple sites, making it an extremely suitable tool for building such a prototype. Second, a development trial was carried out using the groupware system to coordinate the activities of three distributed development groups during the design, coding and testing of a database reporting system. During the trial, the effectiveness of the delegation model of working, and the suitability of the Notes system were
Conference on System Sciences -
1996
evaluated.
Development Trial: Planning and Preparation Logistics
The trial was designed to run as a prelude to the staged implementation of the groupware system in live projects. Therefore it was decided to design a trial which utilised a virtual team in which all members were physically located in Sydney. To simulate distributed working across timezones, 2 developers were based at BT’s premises (APSEC), one developer was based at The University of New South Wales (UNSW), and one developer was based at the University of Technology (VI’S), Sydney. A main Notes server was located at APSEC, and the groupware system and email was replicated over telephone lines to additional Notes servers based at the two other sites. Further, arrangements were made for the developers located at each site to work disjoint work hours, to simulate the teams residing in different locations around the globe. These arrangements are depicted in Figure 1.
Figure 1 Trial arrangements Development
Project
The development project selected was to extend the functionality of a production system in use at the University of New South Wales. The existing system supplied a graphical user interface (GUI) and database access to enable students to register their details in a programme to find them employment after graduation. The required extensions added reporting and querying functions to the system. The system had been developed in C++, and had been in use for nine months. The requirements specification for the project was drawn up 3 weeks before the trial began, and its contents reviewed and agreed upon. From the requirements, the deveIopment was divided up into five modules, each representing a distinct user transaction with the system. Development
Process and Team Structure
Given these requirements, and the nature of the
13
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
Proceedings of the 29th Annual Hawaii International
problem, we decided to divide the development of each module into two phases, namely the GUI component and database accesscomponent. These could be designed and coded separately by different developers. The database component was then to be formally tested before integration with the GUI code and subsequent submission for module testing. This process was to be repeated for all five modules. Further, two of the virtual team members, one at APSEC, one at UNSW, were allocated the responsibility for designing and developing all the GUI and database access components respectively. The other team member at APSEC was allocated the responsibility for designing tests and testing all the database components, and the final team member at UTS was to test the integrated GUI and databasecomponents for each module. The significance of dividing up the development process in this manner is that it creates constant opportunities for performing activities concurrently. For example, once the database interface design has been agreed, the detailed designs for the GUI and database access components for a module could be performed simultaneously. After review, coding of both components can start, while at the same time the test specifications for each can be developec Testing and fault correction IModule -Student Task Ref 5 6 7 6
9
1: 12
Figure DAY LF
n-i KY IG
1 $
2 9
7 2 l/2
48
7 600
2
Task Structure
In order to clearly document this development process, each module was further sub-divided into individual tasks for each required activity (e.g. design, coding, testing). Each task was then allocated to a team member. The dependence relationships between tasks were also documented in a simple activity diagram, and a task schedule was drawn up to depict the relative order the tasks should be performed in. An example of these is shown in Figures 2 and 3. A total of 38 tasks were created.
Task Breakdown
3
4
5
17/21 KY15 16 18122
21 15120 19 22
6 25 20 24 26
Figure
3
1996
can then be performed simultaneously, while the design specifications for the next module can be commenced. This degree of concurrent activity is crucially important in reducing project development times, and especially so when attempting to exploit overnight gain effects. In the latter case, it was anticipated that the overnight gain effect would manifest itself in situations such as asynchronous review completion, asynchronous fault detection and correction, and asynchronous completion of a dependent task. All of these have the potential to greatly improve progress on the project
List Dlaloa Box Task Type Interface design DB access design Interface test spec DB access test spec Interface code DB access code DB access test Corn plate InterfaceIDS
13117 12 8/11 14
Conference on System Sciences -
Allocated (W UG) (IH) I::: (IG) test
for Student Lii
7 29 20123 27 30
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
Dialog Module
8
9
10
33 23128 32 34
BUG FIX 28131136 35 BUG FIX
BUG FIX 37138 Finished BUG FIX
Project schedule
74
la
Proceedings of the 29th Annual Hawaii International
Conference on System Sciences -
1996
Measurement and Evaluation Techniques Virtual Team Communications
We planned to evaluate the trial both quantitatively and qualitatively. Both sets of measures would be valuable in assessingthe usefulness of the groupware system, and the development process employed. The most important quantitative measures were deemed to be: l the proportion of time spent by each team member performing asynchronous communications using the groupware system l the amount of synchronous communications l the number of times team members successfully synchronised activities and exploited the overnight gain effect l the amount of time team members were delayed waiting for dependent tasks to complete In order to obtain the data needed for such measurements to be meaningful, each team member was asked to complete a daily time-sheet. The timesheet allowed each person to record which activities they had spent time on, at minimum resolutions of 15 minutes, choosing from a list of appropriate categories, shown below: l Design Specification l Test Specification l Coding l Testing l Synchronous Communications l Review l Notes Prototype Usage l Waiting/Delayed l Work on other projects/other activities In addition, each person recorded daily whether they had been able to exploit the overnight gain effect. If not, they were asked to estimate how much time was lost due to waiting for a task to complete, and also to record the reason why progress had been delayed. Again, a list of typical reasons was provided, along with the option to add others. When such delays were experienced, they were marked in the timesheets as Waiting time. In order to acquire qualitative judgments about the trial, a shared Notes database was built to allow ideas and opinions to be quickly recorded, commented on and categorised by all members of the virtual team. This discussion database acted as the group memory during the trial, facilitating structured discussion, stimulating ideas about the process and the groupware prototype, and recording this for later processing. In this manner, it acted as an effective tool for process and feature improvement in subsequent developments of the groupware system
The groupware system provided facilities for asynchronous communications amongst team members. Each team member could use the system to view the status of dependent tasks, monitor Status Reports and Task Completions, and receive Review Requests. Deliverables such as design specifications, program code, executables and test results could also be easily transferred between team members. Notes email provided a means to communicate ad hoc messagesand files asynchronously. However, there was no specific technological support, for example videoconferencing, provided for direct synchronous communications. Synchronous communications were in addition especially problematic due to the time and physical displacements of the team members. Consequently, in order to provide target time periods for team members to synchronise and communicate, convenient overlap periods were defined. These were: l 8am-loam between UTS and APSEC l 2pm-4pm between APSEC and UNSW Overlap periods were designated as times when team members could communicate synchronously, using telephone or fax, to clear up problems, obtain clarifications, or discuss ideas. Synchronous communications were not permitted at any other times. Note that the time differences did not allow any overlap period between the UTS and UNSW sites, simulating extreme cases such as developers residing in Sydney and New York. We did not anticipate this causing any significant problems however, as the team member at UTS was responsible for testing the GUI code produced from APSEC, with testing of the database components being performed by a team member at APSEC. For this reason, the need for direct communications between UTS and UNSW was expected to be minimal. In addition to overlap periods, handover times were designated for each site. A handover time defines the time by which a team member should submit Status Reports on all active tasks, and ensure that any deliverables are made available for other team members to use. Handover times were specified to be during overlap periods so that remedial actions could be commenced if task handovers did not take place when planned. The two handover times were: l 9am between UTS and APSEC l 4pm between APSEC and UNSW Due to the time displacements, there was no need to impose a fixed handover time for the UNSW site.
75
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
Development Trial: Proceedings
three team members were able to devote the majority of their time to the trial, with only one distracted by other work for approximately 50% of the time. Throughout the trial, team members used various views of the groupware prototype to monitor the progress of tasks. For example, the status of a task could be monitored by viewing the Status Reports that had been issued for that task, as illustrated in Figure 5. In addition, completed tasks could be easily monitored, as shown in Figure 6. When errors were found during testing, error reports were stored in the prototype. These could be viewed through a dedicated view which gave the status of each reported error (Figure 7). Finally, the results of task reviews were easily accessible (Figure 8). Due to the small nature of the team, and the limited time available, most deliverables were only reviewed by a single person. The trial progressed well, and the was completed early during the last day. Team members managed to communicate and synchronise using email and the groupware system, although some synchronous communications was required during overlap times. The discussion database was widely used, with 76 messages being recorded.
The trial ran for two weeks during February, 1995. In the week before the trial started, each team member was fully briefed on the plans and development process involved, and the groupware prototype was tested with all four people working on a sample task. Next the task breakdowns for the trial were entered into the Notes prototype. Each task was allocated a unique integer identifier and was represented in the system by a Task Specification form. The complete set of tasks could then be viewed through an associated Notes view. An example of this is shown in Figure 4: this view (like all other examples in this paper) was taken after the end of the trial. During this process, each task was allocated to a team member. This was done through the creation of a Task Allocation form, one for each Task Specification. The trial started on a Monday, with activities starting at APSEC, followed by UNSW, then UTS. For the first day, one APSEC-based team member was forced through necessity to work on another project. This caused Sew delays however, since this person could not start on the project until a related task at UNSW was completed. For the remainder of the trial,
Figure
Figure
View of Task Specifications
4
5
Status Report Monitoring
76
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
I YY6
Figure 6
Figure
Figure 8
Task Completion
7
Monitoring
Monitoring
error status
Task Reviews
We also asked each person to record how much time they necessarily spent on other projects, an inevitability in a dynamic commercial environment. The Other column represents this value, a total of 22% of all recorded hours: it is worth noting however that approximately 50% of this amount was recorded by a single member of the testing group. A total of 15% of the recorded time was also spent waiting for work from people (the Waiting column): again other
Quantitative Evaluation After the trial was completed, each person’s timesheets were processed and a set of results compiled. Figure 9 shows the raw results collected from the timesheets: all figures are in hours. Throughout the two week trial period, each team member worked on the project as their principal task.
77
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
npproximately member
50%
01. the
suggest
that
testing
rcquir-cd
Figure
our
development
~hc
[5]
~hc
modules
Test-cases,
results
wore
with
cxpcctcd
test cnginccrs
co&
with
In Figure
by a mcmhcr
(white-box
at Icast
modules
writing
work
The trial
duration
value studies, lhcir
combined 9, 37%,
Othrr
spent
on non-project
is in [act rather in which time
assignmcnt[
lower on
The
values
60%
that
other figure
was
37.75 13%
60%
their
21 7%
Activiw Tot&
[ 121. Thcsc
activities
consume
face-to-face
meetings
early
activities.
Of’ course, Olson
during
phases
tools
the
of’ the development
1425 5%
19.75 7%
42 15%
and
282.25
Time Usage By Development and Testing Groups
53
21
10.5
20.5
14.25
19.75
24%
16%
5%
9%
7%
9%
Breakdown of Time Spent Directly on Trial
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
42 1 Y/o
doex
meetings
Raw timesheet results
17%
in on
;I tentative
cyctc.
63.5 22%
time
face-to-tam
by
20.5 7%
the
working
is
meetings, outside
not
with
of this
bl
was
coordination
mca.surcs
design
to indicate
01’ teams
overheads
37.75
Figure 11
Althou,@
show
20%
lcast
unstructured
other
10.5 4%
Figure 9
Figure 10
comparahlc
is
in
only
represented coordination
introduced
CSCW
certainly
coordination
wcrc
seem
using
It
LIS
hours
interaction
overhead
findings
design
test +
activities.
hours
would
A
IO%
review
major
ohtaincd
53 19%
figure the
at
+
manapemcnt.
cmpiric‘ll
consider
of
and
team
weeks.
distributed
when
removed
the two
fi)r group
project
[ 1 11, this
partly
each
of the rccordcd testing
instance
of Dual
time
coding
prototype
working
intcractlons
this
in other
to spend Ihan
this
comparison,
01‘ the
Howcvcr,
rcportctl
arc lound
tasks
f’rom
amount
work.
than
dcvclopcrs
working 101.
Wtritiq
a signil.icant
during
asynchronous
signif‘ic:mt.
that
for one of‘ the testing
and
rcprcscnt
scarce
in
distrihuted
a
group. Figure
remains
the
1757 of recorded
and
in
that
test I-esults
It is cstimatcd
process
research
by
cIlects
h;ls hecn
only
+ 24’%
coding,
only
the
to bc at least
column
lest spcc + 7%) review)
and
made
seem
design
on design,
limit
to he used
figure.
to the trial
(9%
Importantly,
Furlhcl-,
group
dcvoted
period.
found
work/rcsourcc\).
reflect
use of the groupware
lo
grvc
W;IS
produced
combinations. ;I day’s
that
which
of SY%
spent
reporting
testing).
query
automatically
input
9%
Irom
non-dctcrministic
of the devclopmcnt
which
total
thcrcforc
1 1, the Other
results
wcrc
;I method
to
other’s
would
not have
tcsls
for
for such a high
involved
and did
devising
complex
friosl
ontput,
(waiting
12 month
project,
study
rcsponsiblc
test
directly simply
thcrclore complex,
or
coverage
01. tho
dcvclopcd
Testin, 0 then
the
assignment
under
appropriate
one
tx:
member
attempted.
in
a
developers
VII
rnay
black-box
scqucnccs
saved
This
and only
fi)r all possible this
was spent
work.
blocking
results,
themsclvcs
test harness
the trial
li)r
that 52%
over
most than
orgmisation
and displaying
actual
easier
showing
period,
on more
to give
The
maximum
working
quci-ying
anomalies.
lesling
01
13 dcvelopcrs this
motJulcs,
comparing
input
During the
view,
that
specifications.
concern
amount
monitoring
to
‘output’
and expectctl
nscr
by ;I tend
mostly
was
the &sign
01‘ the
during
facts
rccordcd results
high.
this
waiting
were
the databnsc data
estimates
time
or
was
Thcsc
somewhat
g~-oups
by
cxplainetf
value
group.
initial wcrc
projects
testing
this
i 0 corrohoratcs
of the testing other
of
testing
218.75
not or in
r-.Further.
the
dcslgn,
code
using
virtual
results
and
Only
intcructions located
APSEC
teaIn
made
a total
indicating
poor
that
5%
of
of the
thcrc
wcr(:
and
communications
by the that
this
day. The
co-
!ocated
each
few
unclear
Each and
mcmher
hcen
the
number
in
project.
oi
still
in pi-ogress,
clcpcndcnt losses (5).
with
23
Still,
to distrihutctl tasks
members
can exploit
Estimates
waiting
rcsls stage,
towards
were
being
overnight
was the
to
totalcd the cnti
pertc~rmetl guns
wcrc
in
hc
the
as common
this
this
trend
or 50%
and
errors
cxpericnccd.
lx:
tinIc
50% when fixed.
work the
(hat day.
project
was of the
rccoiclcd
merely
mcmhct-.
of the
This Iroin
mcan~
that
Iriakinf
uscl.ul in
the
pi-ogress
work
future
magnitude
by the day in
had
hecn
trials,
of’ the
more
overnight
he attcmptctl. worthy
hel’orc
~hc hcncl‘its was
thcrcf’orr
of mention
al-c:
3X Task
Allocations,
At
wcrc
the trial
the: end
3. I.17
tcaIn
01‘ the
was (SW
Spccilicdions
created
from
and 38 the
began.
This
took
trial,
the
prototype
project
one dcvclopcr
of
the
243
an
docurncnts,
4.4
or on aver-age
ciatahnsc
addition new
of’
docurncnts
166 per
IXk.
gains.
in waiting
team
documents,
doamients.
inter-
hcfhrc
remaining
of’ the project
to
vaiucs
contained
l”-ohlcm
overnight
resulting
2.
due
Sufficient
completed
The
testers
day
m~s
2.5 hour:,.
~1%
gaius losses.
time
I‘ouncl,
A success
and
shoultl
‘76 Noba plan
3
to
to attend
were
not inipcdctl
nicasurcs
Olhcr I,
lJ7‘S was
task,
gain cIl’cct
Task
first
ovcrnight ovcrnight
projecls.
2 I hours.
time.
l.act,
cxpcct
~hc:
on the final
due
o\*f~r-rIi~ql~r. Certainly
stringent
6,
when
of the two
asynchronous
01‘the
mcmbcr
on ;I given
it ilnpcGi>lc
allcviatc
team
have
trial,
virtually
start
would
Iossc‘s, 4 fronl
that. 2
of’ lost progress,
rccordcd,
cl‘t’cct during
making
hclpcd
wc
slightly. dependent
gain
In
Al’tcr against
coInInitIncnts
loss
01 the time of the
tasks.
the staggcrcd
coInInon
recorded
days
(4) were
gains
Undoubtedly
progrc:;s
i-ciorded hy the iinal
tlciivcrahlcs were availahlc time. or start of the work
ha~~tlovcr
perlormcti
of the overnight
wcrc
dominnted
recorded
34)
three
overnight
to other
from
first
overnight
the
tcam
cf’fcct.
~111overnight
the cast
12:
work
person
crroI-s
mcmhcrs
on the trial
was mucle to quantify
gain
dcsign,~tctl
prohlcins in Figul-c
did
10
ih :,upporteti
con~plcte.
No attempt when
clfcct,
loss.
the overnight
(2X
majority
IO commence
hcing
reprcscnt
in the
tasks
days.
thercfr)rc
f’urthcr
on the project This
team
hcncc
I), was Lhc first
whethet
when
who and
no
01
gain
arc showrl
net overnight
82%
The
losses
hrnccs
daily
of the
Figure
instructions
rccoI-dcci
li)r this
encouragingly,
expcrif-mccd
early
rcsults
thr each
occurred
IJTS,
work
occupied.
working
When
instances
the overnight
progress
The
Most
also
able to exploit
cstinialcd
dcvelopcd. sstiinates
one tcstcr at
overnight ~carn
had
three
I‘inished
the
explanations. they
lhat
had
fully
tca~n
throughou[
very
l‘act
two
outstanding
mombcrs
they
and
by the
calls
tcaIn
synchi-onous
On avcrugc,
of‘ 2 phone
not enough
hcep
synchronous total,
interactions
simply
module
pcrformcd
little
mcmbcrs.
that
thesis
adcclLI”t”ly
hours
direct
mcmbcr
our
with
rccordcd. by
Overnight Gain Efft3A~:~28 from 34 time lost due to failures: 21. hours Figure 12 Overnight Gain Effects
hc
10.5
were
dominated
trial,
CL111
te’1m.s L
interactions. was
support
test
Sgccessfu! Estimated
total was
the find Al
this
hut thcrc
wa
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
nia~l-enablcti
project per day,
with
on days
I and
project
documents
nI;rnagcr
during a peak
completions ciocumcnts
and wore
auU~matically
of’ !hc status error
sent
an average
to
Copica
01 7
nolif.icd
the
tasks.
task
of on-going
reports.
also stored
the
of 13.7
ot 2 I on day 6, and a low
IO. Thcsc
nlnnagcr
wcrc
the trial.
01 all
in the protolype.
thcsc
Proceedings of the 29th Annual Hawaii International
Qualitative Evaluation and Suggestions for Improvement
Email Usage
Unlike in other studies[lO], and due to necessity, there was no reluctance to use email to communicate over a range of issues. Team members were mostly diligent in making sure all relevant details were included in an email. In some cases however, important details were left out of emails, causing delays in the project. For example, one developer received a mail containing the following message: “Your code does not compile, it gives a syntax
Group Awareness
On the whole a strong feeling of awareness of other team member’s activities was reported. Three of the group reported closely monitoring related tasks and consciously working to ensure expected deliverables were made available at handover times. Maintaining this awareness was greatly aided by the groupware prototype, which allowed team members to easily view and monitor the status of related tasks through Status Report and Task Completion Report submissions. Undoubtedly in a distributed working environment, a high level of group awareness is necessary for project elapsed times to be significantly reduced through overnight gains. A groupware system to foster and maintain such a working environment would consequently seem indispensable.
error”
To act on this message, much more information was needed, such as which code file raised the error and the exact error message produced. In this case several more emails were needed to solve a very minor naming problem, wasting both developers’time. We expect that these problems could be alleviated by building email templates for team members to use. A different message template would be provided for each general type of message, such as a technical enquiry, non-technical enquiry, process enquiry, and so on. The templates would contain message fields, with attached hypertext help, to serve as reminders of the type of information that is typically included in such a message.
Anxiety
Failure to respond promptly to an email, review request or error reports brought about considerable nervousness and anxiety in team members. If the desired responses were not available at handover time, emails were sent and/or phone calls were made to try to resolve the problem. This wasted time and impeded progress. Everyone felt a need for some form of automatic reminder service, which would monitor all emails sent out, and send reminders if a reply was not received by some stipulated time. A priority system to allow escalation of unresolved issues would be a valuable feature of such a service. Intelligent
Summary of Trial Results The most important findings of the trial were: 1. Team members spent on average 22% (17% asynchronous, 5% synchronous) of the time devoted to the project communicating and coordinating activity with other team member, and performing project management activities. 2. 82% of opportunities to exploit the overnight gain effect were successful. Although the trial did not attempt to quantify the productivity gains experienced, anecdotal evidence from the team member’s experiences indicate that they were significant. Further research is needed to decide how such productivity gains should be measured. 3. Blocking of activity due to the 6 overnight losses (failure to deliver results in time) caused estimated delays of 21 hours, an average of 3.5 hours each. This is a significant figure, and emphasises the importance of minimising overnight losses. More
To-Do Lists
Group progress was heavily dependent upon each individual fulfilling their requirements and promptly responding to emails, review requests and submitting regular status reports. Failure in any of these activities, usually through forgetfulness and pressure of work, could potentially substantially delay another team member. All trial participants commented that such problems could be somewhat alleviated by a tool 80
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
1996
providing To-Do list functionality for each team member. The To-Do list could track allocated tasks, issue reminders when Status Reports were due, alert people to urgent emails or overdue review responses, and provide a private, configurable view of the contents of the project database
The major vehicle for performing qualitative analysis was the group memory database provided by the Notes prototype. Two team members also produced single page postmortems, summarising their experiences, thoughts and ideas. The most important ideas and comments related to asynchronous group interactions are briefly presented below:
Team Member
Conference on System Sciences-
Proceedings of the 29th Annual Hawaii International
research is again needed to explore the most common reasons for overnight losses, and to devise ways to minimise their effects. 4. Lotus Notes proved a suitable tool for implementing a groupware prototype for supporting distributed software development teams.
Conference on System Sciences -
1996
References 1. Conklin,P.F., Enrolment Management,Managing the Alpha AXP Program, Digital Technical Journal, 4, 4
(SpecialIssue1992) 2. Dase,M.A., Tung, L-L, Turban, E., A Proposed Research Framework for Distributed Group Support Systems, in Proceedings of the 28th Annual Hawaii International Conference on System Sciences, Volume IV, Information Systems Track, Maui, January 3-6, pages 42-51, IEEE 3. Prasad,B., Morenc,R.S ., Rangan,R.M., Information Management for Concurrent Engineering: Research Issues, in Concurrent Engineering: Research and Applications, vol 1, no 1, pp 3-20, 1993 4. Constantine, L.L., Work Organisation Paradigms for Project Management and Organisation, Communications of the ACM, 36, 10, pp 34-43, October 1993 5. Norris, M. And Rigby,P., Software Engineering Explained, John Wiley and Sons, UK, 1992 6. Gorton, I and Motwani, S. , Towards a Methodology for
Conclusions and Future Directions Some software development organisations are recognising the potential benefits of exploiting time differences between widely geographically separated development teams. Surveys of the literature indicate that such recognition is mostly a by-product of necessity. For example, [13] and [143 reported experiencing productivity gains and lower costs due to time differences. However distributed teams were chosen for many and varied reasons (e.g. cost, expertise, customer locations), with neither explicitly planning or expecting to exploit overnight gain effects. On the contrary, this project has explicitly recognised the potential to exploit overnight gains. Consequently we are attempting to design new, highly concurrent software development processes and groupware support tools to enable distributed development groups to advantageously utilise time differences. The successful completion of this trial has been a major milestone in the project. It has given us confidence that our ideas are valid in a small team context. It has demonstrated the value of employing groupware technology in distributed team software engineering environments. It has shown that team members can communicate, synchronise activities to exploit the overnight gain effect, and accomplish reasonably complex tasks asynchronously, with a minimum of direct communications. Further, we have quantitative data which indicates that, at least for small groups, asynchronous problem-solving does not seem to introduce significant interaction overheads. What is still uncertain is whether this mode of working will scale up into large, complex developments with fifty or a hundred or more team members in widely separated groups. We also cannot be sure how factors such as the communication skills of team members or the nature of the tasks performed have influenced the results. Our aims are therefore to improve and generalise both the development processes and groupware tools used in this trial, and widen their scope to integrate common project and configuration management tools. Further development trials utilising larger teams, performing a variety of tasks and producing a complex product will then be needed to act as more conclusive arbiters of the approach.
24 Hour Software Production Using Geographically Separated Teams, in the Proceedings of the First IFIP International Conference on Software Quality and Productivity, Hong Kong, December S-7th, Chapman and Hall, pages 50-55, 1994 Kraut, R.E. and Streeter. L.A., Coordination in Software Development, in Communications of the ACM, 38, 3, pp 69-8 1, March 1995 G.Forte and R.J.Norman, A Self-Assessment by the Software Engineering Community, Communications of the ACM, 35,4, April 1992,pp 28-32 I.Vessey and A.P. Sravanapudi, CASE Tools as Collaborative Support Technologies, Communications of the ACM, 38,1, January 1995, pp 83-95 10. D.E.Perry et al., People, Organisations and Process Improvement, IEEE Software, vol 11, no 4, pp 36-45, July 1994 11. Burke, K., Chidambaram, L., Locke, J., Evolution of Relational Factors Over Time: A Study of Distributed and Non-Distributed Meetings, in Proceedings of the 28th Annual Hawaii International Conference on System Sciences, Volume IV, Information Systems Track, Maui, Januray 3-6, pages 14-23, IEEE 12. Olson, G.M., Olson, J.S., Carter, M., and Storrosten, M., Small Group Design Meetings: An Analysis of Collaboration, in Human Computer Interaction, vol 7, no. 4, pages 347-374 13. G.Dedene and J.P. De Vreese, Realities of Off-Shore Reengineering, IEEE Sofiware, vol 12, nol, pp 35-45, January 1995 14. Hrones,J.A., Jedrey, B.C., and Zaaf, D., Defining Global Requirements with Distributed QFD, Digital Technical Journal, ~015, no 4, Fall 1993 Acknowledgements: The authors would like to acknowledge the efforts of the following: Sanjeev Motwani, Dave Beale, Kris Yiu, Martin Deacon,Sylvia Grant, David Johnson. We would also like to acknowledge the support of BT Australasia and the Australian Research Council.
81
Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE
