Department of Computer Science

Series of Publications C

Report C-2004-65

Experience in a distributed

cross-cultural

student software project

A. Inkeri Verkamo, Juha Taina, Yury Bogoyavlenskiy,

Dmitry Korzun, and Turjo Tuohiniemi

University of Helsinki

Finland

Contact information

Postal address:

Department of Computer Science

P.O.Box 68 (Gustaf Hallstromin katu 2b)

FIN-00014 University of Helsinki

Finland

Email address: postmaster@cs.Helsinki.FI (Internet)

URL: http://www.cs.Helsinki.FI/

Telephone: +358 9 1911

Telefax: +358 9 191 51120

Computing Reviews (1998) Classification: D.2.9, K.6.1

Helsinki 2004YliopistopainoPikapaino

Experience in a distributed cross-culturalstudent software project

A. Inkeri Verkamo†, Juha Taina†, Yury Bogoyavlenskiy‡,Dmitry Korzun‡, and Turjo Tuohiniemi†

{verkamo,taina,tuohinie}@cs.helsinki.fi{ybgv,dkorzun}@cs.karelia.ru

† Department of Computer Science, University of Helsinki‡ Department of Computer Science, Petrozavodsk State University

Department of Computer Science, University of HelsinkiTechnical report, Series of Publications C, Report C-2004-65Helsinki, September 2004, 18 pages

Abstract

Software is more and more developed in international cooperative efforts whereproject team members have different educational and cultural backgroundsand the team may even be distributed among sites in several countries. Soft-ware engineering education should also involve distributed and cross-culturalproject work to prepare the future software developers for this kind of workenvironment. In a pilot project of two universities in Finland and in Rus-sia a cross-cultural student team gathered experience by developing a commonsoftware product in a distributed project. While in general the project was suc-cessful, the team encountered some problems mainly due to the need to workin a foreign language and the practical limitations of remote connections.

Computing Reviews (1998) Categories and Subject Descriptors:D.2.9 Software Engineering: Management: Programming teams

K.6.1 Management of Computing and Information Systems: Project and Peo-ple Management: Training

General Terms:Experimentation

Additional Key Words and Phrases:

1 Introduction

Software development in our increasingly international world involves moreand more cross-cultural software teams. The movement of work force fromone country to another is likely to increase now that currently effective bar-riers are lowering. Moreover, there is strong emphasis to bring educationalsystems closer to each other, further improving the possibility of students toperform part of their studies in a foreign university, which will eventually alsolead to more people spending at least some part of their work career in a foreigncountry. Hence it is very probable that anyone involved in software develop-ment will sooner or later be required to work in project teams consisting ofpeople with different educational and cultural backgrounds, perhaps commu-nicating in a language that is not native to some or most of the participants,and certainly requiring to overcome different conceptions, working habits andbackground abilities of the project team.

The availability of fast and efficient communication media such as email, tele-conferencing, web forums, etc. promotes the possibility of distributed projectwork where people working on a common software product reside on severalsites, perhaps never even meeting each other in person. While the problemsand misunderstandings resulting from a distributed work environment shouldnot be neglected, there are also numerous advantages in such arrangements,including the freedom to remain in one’s original environment, and to work ina local familiar setting and within a stable team. Even now many large soft-ware companies have assigned common software projects to distributed teamsworking in their branches in several countries, which allows taking advantageboth of available skill and talent and the cost of labor in various parts of theworld.

A fairly realistic software engineering project covering all phases of softwaredevelopment is an important part of computer science education. For inexpe-rienced students even a small and local project is typically a very enlighteningexperience, where the students learn both about the subject matter of theirproduct and about project work more than what the best teachers could pos-sibly teach them in a classroom. To a certain extent, such a project should berepresentative of the environment where the students may expect to work intheir future, yet for the purpose of learning the best practices of software en-gineering, such projects should be arranged in a controlled educational settingrather than in an actual industry environment.

While software engineering education and team work has been widely dis-cussed in the literature, little has been written about distributed studentprojects. Brereton et al. discuss distributed student work across several organi-zations [6, 7, 8]. They present promising results of a geographically distributedstudent project, but in their study the students have a homogeneous culturalbackground and hence it does not involve a cross-cultural aspect. Yet it is

1

2 PARTICIPATING DEPARTMENTS 2

obvious that cultural differences do exist, and software engineers in differentcountries have adapted different working methods, as Cusumano et al. haveshowed in their recent study [9].

To combine the learning experience of a student software project and the realworld problems of distributed and cross-cultural work, we arranged a commonsoftware engineering project for computer science students in two universi-ties. In this project, a single software product was produced in cooperationby students working concurrently in Helsinki, Finland, and in Petrozavodsk,Russia.

In this report we describe some of the experience we gathered in this project.The emphasis of the report is on lessons learned on cross-cultural and dis-tributed project work rather than on the subject matter of the product pro-duced in the project.

The rest of this paper is organized as follows. In Section 2 we introduce theparticipating departments and their software engineering education. In Sec-tion 3 we describe our joint distributed software engineering project. Section 4characterizes the basic concerns that we had with respect to the project andSection 5 collects the most important lessons we learned from the project.Finally, Section 6 summarizes and concludes the paper.

2 Participating departments

The Department of Computer Science in the University of Helsinki (DCS-UH) [12] and the Department of Applied Mathematics and Computer Sciencein Petrozavodsk State University (DCS-PetrSU) [13] have had cooperation inresearch and education for more than ten years. The main areas of common in-terest have been data communications, distributed systems, and performanceevaluation. The cooperation is based on mutual visits of teachers and re-searchers, and an annual scientific seminar “Advances in Methods of ModernInformation Technologies” arranged in Petrozavodsk with participants fromboth universities as well as from some other universities in Russia and in Fin-land. In addition to the oral presentations, biennial proceedings of the seminarsare published [1, 2, 3, 4].

The next step in enhancing this cooperation is in the field of software engi-neering. Both departments have experience of SE student projects but theiremphasis and styles have been different. In DCS-UH the student project isthe first attempt of the students for working on a real or almost real softwareproblem while in DCS-PetrSU the student projects are more abstract and the-oretical. Both departments were interested in sharing their experience in adistributed cross-cultural project.

2 PARTICIPATING DEPARTMENTS 3

2.1 University of Helsinki

In DCS-UH, a software engineering team project has been a part of the teachingprogram since 1985, and since 1990 it has been mandatory for all studentsmajoring in computer science. The project is in the final year of the curriculumof undergraduate studies. At this stage the students have taken mandatorycourses in programming, operating systems, data structures, databases, andsoftware engineering. They have also produced small scale software as singleperson projects, but these are much smaller in volume and in duration than thesoftware engineering project. Some students have also worked part time duringtheir studies so their experience in industrial software development varies fromnone to several years. The software engineering project is performed in teamsof 4–6 students and it is often the last course before the Bachelor’s thesis. Themain programming language in DCS-UH is Java, but some students have alsotaken elective courses in C or C++.

As a rule, each project team has an individual topic provided by the staff of thedepartment. Some projects produce software for an external customer, such asresearchers in other departments of the university. A typical product producedin a student project is a well defined piece of software required by a researchgroup, an administrative software tool, or some educational software to be usedin teaching computer science. The project covers all phases of the product lifecycle from requirements definition to system testing and installation.

For each project team, a member of the staff (or correspondingly someone rep-resenting the external customer organization) is assigned as the customer. Ateaching assistant is responsible for advising in the technical work (CASE tools,documentation requirements, etc.), but the team members assign a projectmanager amongst themselves and they are responsible both for scheduling anddividing their work. The timespan of the project is one semester, i.e. 12–14weeks, and the students are expected to work in the project for about 20hours per week. To assure the comparability of the various student projects,one teacher supervises all the projects running in parallel (typically around10 teams per semester), participating in all document inspections and in theevaluation of the final products.

2.2 Petrozavodsk State University

DCS-PetrSU has been a part of the Faculty of Mathematics since its creationin 1989. The studies in the faculty are divided in three specialization areas:“Mathematics”, “Applied Mathematics and Computer Science” (AMCS) and“Information Systems and Technology” (IST). The software engineering courseis mandatory for the last two areas (AMCS since 1989, IST since 1999), and itis in the third year of the curriculum of undergraduate studies in AMCS andIST. At this stage the students have taken mandatory courses in programming,

3 DISTRIBUTED PROJECT 4

application and system software, databases, algorithms and data structures,operating systems and computer architecture.

DCS-PetrSU has a strong emphasis in applied mathematics. The volume ofcomputer science courses is only about one third of the total studies for theBachelor’s degree. Only a few of the third year students have also worked parttime during their studies so they do not have a lot of experience in industrialsoftware development. However they have had several small personal projectsin theoretical and applied algorithms, data structures and C/C++ program-ming. Each course typically involves laboratory work (50–75% of total volumeof studies, or 2–5 hours per week).

A software engineering team project has been included as a part of the SEcourse and it is arranged in parallel with the lectures. The project is per-formed in teams of 3–5 students. The main attention is on theoretical aspectsof software development; the teams concentrate on design and algorithmicproblems. As a rule the target software is a simple computer game or a puzzle.The team instructor also acts as the customer.

Since 2001 DCS-PetrSU has a new specialization subarea of “Distributed Sys-tems and Data Communications”. The idea of this subarea is to constructa common core of working study program (CCWSP) in computer science [5].According to CCWSP, the SE course and SE team project in DCS-PetrSUshould be similar to the ones in DCS-UH. The lectures have been similar sincethe autumn of 2003. For most students the SE team project has been similarto the previous one in DCS-PetrSU, but since 2003 students of this specializa-tion subarea have had an elective course of an extra SE team project, similarto the one in DCS-UH. Therefore the new SE team project is only offered toa small number of students majoring in this specialization subarea.

3 Distributed project

Figure 1 shows the structure of our distributed project organization. Theproject involved 11 students in two universities, two supervisors, two instruc-tors, and one customer.

Since we expected that the project would demand the students an exception-ally large effort, including the use of a foreign language (English) for projectcommunication and documentation, and a visit to the other university, weformed the student team exclusively of students volunteering to join this par-ticular project. In all there were eleven students in two subteams or groups:The H group at DCS-UH consisted of four Finnish students and two Span-ish exchange students; one of the Finnish students was bilingual (Finnish andEnglish). The students in the H group were in their final year of undergrad-uate studies. The P group at DCS-PetrSU consisted of five native Russianstudents, four of them in their 3–4 year of studies (undergraduate) and one in

3 DISTRIBUTED PROJECT 5

students

projectsecretary

groupleader

Customer

Supervisors

Instructor I Instructor II

maintains

email

email

project managergroup leader and

CVS

Web pages

Forum

students

P GroupH Group

repo

rts

reports

full

acce

ssfull access

email list

Figure 1: Project organization

the first year of his master’s studies. Four of the students in the P group hadparticipated in a common pilot project during the previous semester. One ofthe Finnish students was elected as the project manager of the entire team.The team was provided with common project guidelines describing the phases,the communication media, and the documentation used in the project.

The supervisors of the project were in Helsinki and in Petrozavodsk. Theyacted as the highest administrative managers. Mostly their participation wasonly reviewing and accepting reports of project work, but a few times they wereasked for technical advice about software engineering process tasks. While twosupervisors might cause problems in communication and cooperation, we didnot have any such issues in our project.

Both student groups had a teaching assistant as their local instructor. Due tothe different culture of software engineering their roles were somewhat different:the instructor of the H group was mostly a silent advisor of his group, while theinstructor of the P group had a more active role. Both instructors supportedtheir group very well encouraging the students to learn new skills and to usethem for the benefit of the project.

The customer of the project was a researcher from DCS-UH who defined thetopic of the project to match his educational and research interests. Theproject team was assigned to build an educational tool for visualizing data

3 DISTRIBUTED PROJECT 6

communication protocols by using data captured from the real network. Thetool was intended both for research tasks where network traffic visualizationis needed (see, e.g., Seawind [11]) and as a teaching aid for undergraduatecourses in data communications.

3.1 Practical arrangements

Since this was our first experiment in a distributed student project, we werecautious that the two groups should not be too dependent on the abilities ofeach other. Mostly each group should be able to work independently at theirown site, with a functional local structure and a fairly compact task to workon. Therefore the interface between the tasks should be clearly defined earlyin the project. This was also important to limit the amount of communicationneeded, since there was no previous experience of such heavy use of the internetconnection between Helsinki and Petrozavodsk.

To allow these restrictions, we chose the waterfall model as the overall processmodel of the project. By fixing the overall requirements during the first weeksof the project we could divide the task into two fairly independent parts: theanalyzer that analyzes the log data of two communication links and providesa common representation, and the animator that visualizes the data commu-nication protocol (see Figure 2).

Figure 2: System structure

Taking into consideration the strengths of the students, the division of thetasks was straightforward, with the P group assuming responsibility for theanalyzer part and the H group for the animator part. The most importantpoint of communication between the parts was the intermediate presentationfile produced by the analyzer and used as the input to the animator (see

3 DISTRIBUTED PROJECT 7

Figure 2). This was defined early in the project using XML. The customerprovided input material for the analyzer (data communication log files), andthe goal of the project was to produce a prototype system that would be easilyexpandable to present various types of communication protocols.

The independence of the two parts allowed each group to use those tools thatthey were most familiar with, including the choice of programming language(C for the analyzer and Java for the animator), CASE tools (both groupsused mainly dia for UML diagrams, but other tools varied depending on theprogramming language and the task), and documentation tools (both groupsused LATEX). For configuration management, the team had a common CVSrepository in Helsinki, and the P group accessed the CVS over the internet.

While in principle it should be possible to have a distributed project with nocommon meetings at all, in this first experiment we considered it wise to startthe project with a common kick-off period. This was arranged in Helsinki,where the entire team and their teaching assistants spent three weeks workingtogether to define the requirements, divide the work, and establish the timelineof the project. A second common working period was arranged towards theend of the project, when the H group visited Petrozavodsk for a period of tendays for integration testing and a demo of the final software. However, muchof the time scheduled for integration testing was actually used for coding sincethe project was a little late.

Several forms of communication media were used. In addition to direct email,the team used both local and common mailing lists. To compensate for thelack of common meetings and discussion, the team used a discussion forum onthe web with hierarchically structured topic areas. In addition they establisheda set of common web pages for publishing documents, meeting agendas andminutes, and other material.

3.2 Project outline and volume

The project was arranged during the spring semester of 2004, with a totallength of 19 weeks. The final software product was demonstrated both inPetrozavodsk and in Helsinki, and it was approved by the customer. Theproject, called DaCoPAn (visualization of Data Communication Protocol throughAnimation) [10] fulfilled the expectations of the customer and the supervisors.The resulting product is a prototype that will be further enhanced in new stu-dent projects, both locally in the participating universities and perhaps laterin another distributed project.

Table 1 presents some statistics describing the size of the project. The H groupdecided to work two extra weeks after their visit to Petrozavodsk, which ex-plains why they have more hours of work. Also the P group could benefit fromtheir previous common project deliverables which eased their burden especially

3 DISTRIBUTED PROJECT 8

in documentation.

In addition to the documentation, all minutes of the meetings and other teamlevel communication were produced in English and they were available to bothgroups. The team produced a single project plan and a single requirementsdocument, but documentation for design, implementation, testing and instal-lation typically had a common part and separate parts for the analyzer andthe animator.

P group H group Common TotalStudents 5 6 - 11Hours of work (HoW) 1211 1787 - 2998HoW/student 242 298 - 273Emails 124 382 191 697Forum postings 177 119 - 296Meetings 34 24 12 70Documents 4 6 5 15Pages 97 76 151 324

Table 1: Project volume

Table 2 presents information of the volume of the software and the effortrequired of the two groups. Since the groups used different programminglanguages, the size statistics are not comparable. As can be seen from thefigures for testing, the two groups used a different approach in testing: theH group used a great deal of unit testing, while the P group relied more onintegration testing. In fact, the H group did not use a rigid waterfall model intheir work, and their coding and unit testing was mostly iterative.

Analyzer Animator(P group) (H group)

Compilation units 27 77Subprograms 111 425LOC in main program 6333 14058Compiled size 36 KB 382 KBLOC in tests 1416 2179Unit tests 18 75Integration tests 78 12Validation tests 9 13

Table 2: Software volume

4 POINTS OF CONCERN 9

4 Points of concern

We had certain expectations about the kinds of problems that might surfaceduring the project. In order to register all problems and to learn as much aspossible of the difficulties encountered we asked the students to write downtheir comments during the project. During the final phase we also interviewedeach student asking for both positive and negative experience on the coopera-tion and communication of the team, the distributed work in general, and anyother related topics.

We expected that some problems might arise because of cultural differencesbetween the two groups. It is easy to picture that the work culture in Finnishand Russian universities might differ, e.g., with respect to authoritative vs.independent working. Even within one cultural area there are attitude differ-ences, and some students might also entertain prejudices against each other.

Another potential source of problem was the different educational backgroundof the students. Mainly this should be an advantage, allowing the studentsto learn from each other, but we were also concerned that in some areas thestudents might not be able to understand each other and cooperate becauseof too little overlap in their background knowledge.

In our experiment the problems caused by working on separate sites might alsobe more difficult than usual, because of the different facilities offered by ourtwo universities. We had gathered experience in working over the internet,e.g., in writing research papers, but we had not used it so heavily as wouldbe needed during a software project. Another consequence of working on twosites was the fairly complex structure of our project organization, with twosupervisors and two teaching assistants involved in the project.

We were particularly concerned about the problems caused by the need touse a foreign language, not only for documentation but also for all team levelcommunication in the multilingual H group. While all our students were ableto read and understand English, only one of them was a native speaker, andwe were unsure of how sufficient the abilities of the others were.

5 Lessons learned

The joint project was a success both in educational and in research point ofview. We learned a number of lessons, which we can benefit from both in ourother student projects and in our future cross-cultural distributed projects.

5 LESSONS LEARNED 10

5.1 Cultural differences

Perhaps the most interesting results of the project were about cross-culturalaspects: using a foreign language in everyday communication, tolerance to cul-tural and personal differences, group member backgrounds, and commitmentto common goals. One of our greatest concerns was how students having dif-ferent backgrounds would get along with each other. Even one narrow-mindedperson in either group could easily injure the good spirit and cooperation ofthe team. The P group members had worked both together and with us before,but we did not know the members of the H group in advance, and only someof them knew each other beforehand. Fortunately we did not encounter anyproblems. The general attitude and the work morale of both groups was verygood. Whatever their own expectations or suspicions may have been in thebeginning, in the end they were genuinely satisfied with the work of the entireteam. In the interview they mentioned that the team project had been a veryvaluable experience, and they were confident that they had produced a highquality product.

As we had expected, there were some differences in the work culture of the twogroups, especially in their attitude towards team hierarchy and documentation.One of the first cultural differences between the groups was observed duringtheir first common meetings in Helsinki. At that point the P group had alreadyassigned the task of group leader to one of the group members, and theyrepeatedly asked who the leader of the other group was. The members ofthe H group had only just met each other and they were interested in a lesshierarchical group structure; they considered either circulating the leader roleamongst the group or even having no group leader at all. They finally choseto have a group leader, but his role remained much less prominent during theentire project. In consequence, the roles in the P group were more clearlydefined and fixed, while the H group had more flexibility in the division oflabor.

The preferred process model of the two groups was different. In general, theP group was inclined to prefer a waterfall type, document driven approach.As they had already worked together in the previous team project, they sawthe possibility of reusing the documentation of that project as a valuable assetin easing their own work. The H group preferred a more iterative and light-weight process, and they were more willing to delay the documentation tasks,especially after the first common working period where the general timelineof the project and the division of tasks had been established. In the begin-ning, this difference of attitude caused some friction, as the document drivenapproach could be labeled as “too rigid and hierarchical” and the other one as“too undisciplined”. During the project the attitudes of the groups graduallycame closer, and in the end the level of documentation was acceptable bothto the participants and the customer. Both groups used standard documenttemplates that were developed in DCS-UH for software engineering projects.

5 LESSONS LEARNED 11

The time the groups spent working in the same place was very useful. However,since the total time together was almost five weeks out of 19, it somewhataffected the goals of the distributed project. For instance, the students gotto know each other so well that we encountered none of the usual conflictsbetween people who know each other only on the net.

In the future projects we plan to cut the joint working time to 2–3 weeks. Weneed to find ways to arrange distributed group communication especially in therequirements elicitation and analysis phase, to shorten the joint kickoff timeto one week. The joint time in integration testing cannot be shortened muchwithout loss of efficiency. When the software components are merged into afinal product, especially with tight schedules, face-to-face communication re-sults in much better and faster integration testing than distributed integrationbased entirely on email and forum communication.

5.2 Differences in educational background

With respect to the topic of the project, each group had certain areas wherethey were more proficient than the other group. The P group had a strongerbackground in algorithm design which was needed in the analysis part, whiletheir experience in user interface design was limited. The H group in turnwas more familiar with the tools needed for visualization, and they had moreexperience in industrial software development. In this respect, the division ofthe tasks was both natural and successful, allowing each group to build ontheir strengths.

When the tasks were divided to the groups, the proximity to the customer wasconsidered more important to the group designing the user interface. But dur-ing the project this setting also had its disadvantages. In fact the customer hadonly few specific requirements for the user interface, thus giving the H groupa fairly free hand in their work. On the other hand, some problems regardingthe log files used by the analyzer would have required more frequent commu-nication with the customer. In retrospect some of the students remarked thathaving a local customer in Petrozavodsk might have been more important thanin Helsinki, although this could not be foreseen in the beginning.

Dividing the work along the geographical location was not entirely optimal.One of the students in the P group would have been both interested andexperienced to work in user interface design, but due to the division of thework he could not apply these skills in this project. Nevertheless, all thestudents agreed in the end that this division of the work probably resultedin a better product. While one of the H group students remarked that “ourpart was more fun!” the design and implementation of the analyzer part wasalso rewarding to the P group, allowing them to tackle interesting algorithmicquestions.

5 LESSONS LEARNED 12

On the other hand, the purpose of a student project is also to improve theskills of the students in areas where they are not yet experienced, and hencea different way of assigning the tasks might have been more educational, es-pecially if there had been an opportunity to work in mixed groups. Indeed adrawback of the chosen division was that the students had only limited needto study the code of the other group, and so they did not necessarily learnvery much from each other’s expertise. However, forming the groups in anyother way than by their geographical location would have caused so much moreneed for communication that we still consider it too risky for the success ofthe entire project.

One of our concerns beforehand was that the hardware and tool experienceof the groups was somewhat different. This proved to be no problem, sincestudents are accustomed to learning the use of new tools. In fact, the divisionof tasks allowed each group to use mostly tools that they were familiar with,irrespective of what the other group used. For documentation the team decidedto use LATEX, and the only tool problems between the groups were related todrawing UML diagrams for the documents: The groups experimented withseveral freeware drawing tools instead of agreeing to use one common tool. Inthe end all diagrams were presented in Encapsulated Postscript format, whichis sufficient for the present documentation, but may cause problems whenupdating the original diagrams that have been drawn using various tools.

5.3 Remote work

In this project, a potential problem was the internet connection between Russiaand Finland. It is not always fast and it sometimes suffers from unscheduledinterrupts. This could have been a serious problem when using the commonCVS repository over the internet. During the entire project the P group had toadapt to delays and occasional service interrupts. Fortunately they were usedto such problems and organized their work accordingly by doing part of thework locally and checking in their contribution to the CVS less frequently. Tothe H group, the slow connection came as a surprise during the final integrationtesting phase in Petrozavodsk. During the period when the entire team wasworking in Petrozavodsk, they had a local copy of the CVS at the DCS-PetrSUserver, as frequent updates to the repository over the internet would haveslowed down the integration testing to an unacceptable degree.

To compensate for the missing face-to-face meetings, the team used email,common web pages and a discussion forum. In general they were satisfiedwith this set of communication tools. Direct email was not used very much;it was mostly only limited to local communication. On the other hand, themailing lists were heavily used. A recurring problem with the mailing lists wasthat it was not always clear who should respond to a question sent over themailing list. Clearly this is a problem that requires a better defined protocol

5 LESSONS LEARNED 13

to ensure that open questions will be handled in acceptable time.

The discussion forum was found very useful, especially when working on somewell defined question, such as defining the XML interface. Yet the statisticsof the communication volume show that email was more popular than thediscussion forum (see Table 1). This is interesting because in the beginningall participants agreed that the forum should be the main media for commu-nication and nobody wanted to receive any more email. It was not alwaysclear, which communication medium should be used for which purpose, andin hindsight some of the students remarked that they should have defined thisbetter in the beginning of the project. It seems that email is still easier andmore convenient to use than web based forum software.

Communication between the groups is one of the key issues of project success.No matter what the level of coupling is between the software components ofeach group, the groups always need fast and working communication channelsincluding info about when a message has been acknowledged by the receiver.One possible improvement in the next distributed project is to use a chat serverto have online discussions about related problems. However, this requires verygood network connections between the distributed groups.

In addition to hardware related delays, the distributed team also had to copewith delays caused by humans: sometimes other team members were absent, orthey forgot to answer an email, or they had some other priorities. This was notso much a problem locally, since both groups had weekly meeting times thatcould be used for local communication. However, the need for inter-groupcommunication does not necessarily occur during the meeting times of theother group, and when combined to the occasional unreliability of the internetconnection, this sometimes caused unwanted delays in the communication. Ashort delay in answering is not necessarily a problem, if you know that yourquestion has been received, but under the circumstances this was not alwaysthe case.

From project management point of view we noticed that having two supervisorsactually had a positive effect on the project work. Both groups knew that alocal objective supervisor was monitoring their work. When a question arises,it is useful to have a high authority present in person, as all issues cannot besettled by email. Also in other aspects it was good to have local managementfor each group, allowing the groups to work independently after the initialrequirements elicitation phase.

Some minor problems were caused because of the occasional absence of thecustomer. As an active researcher, he had several conference trips during theproject, and at least one document inspection had to be postponed for oneweek because of his absence. During the requirements elicitation phase whenthe groups were together, they could ask their questions from the customer inperson, but at later stages the P group suffered from the distance. When the

5 LESSONS LEARNED 14

customer was in Helsinki, the H group could schedule meetings with him atshort notice, but the P group was dependent on sending lists of questions andreceiving replies through email or on the discussion forum. On a few occasionswhen the customer was not available, the P group had to rely on local expertsto solve a problem. As mentioned before, it would have been useful to havetwo local customers, one on each site. Email and forum discussion was barelyenough to compensate. One alternative would have been videoconferencing,but that would have been difficult to arrange with few benefits.

Working in different time zones could also be a source of delay: fortunatelythe time difference between Helsinki and Petrozavodsk is only one hour, so inour experiment this did not cause additional delays. Other problems mightresult from having different schedules, e.g., because of holidays, but in ourcase the only notable difference in holiday seasons was in the beginning ofMay, when both groups were working in Petrozavodsk. Even so, we had someproblems because the semesters in Petrozavodsk and in Helsinki begin a fewweeks apart. In fact, the first kickoff meeting was slightly too early for the Hgroup so that the students did not have time to get to know each other beforethe joint meetings with the P group. The P group in turn had spare timein the project before the kickoff meeting. This difference in schedules causedsome strain on both sides, but fortunately the students were able to cope withthis.

5.4 Working in a foreign language

The largest source of problems in the joint project was the necessity to work in anon-native language. Particularly in the beginning of the team work, when theparticipants did not yet know each other’s abilities, it was sometimes difficultfor them to differentiate between the various reasons for lack of communication.A team member may be silent because he has nothing to communicate, becausehe is reserved by nature, or because his language skills are inadequate. Culturaldifferences may cause additional problems, since the participants may havedifferent conventions and expectations with respect to the proper order ofdiscussion. The first weeks of the project work are particularly important inmaking everyone feel free and confident to contribute.

In our experiment, the first common work period was somewhat difficult. Atthat time all P group members were still inexperienced in spoken English whichcaused them to be much more silent and even passive in the common meetings.They were more confident in reading and writing in English, and in the longrun the level of their language skills was quite adequate. The English abilitiesof the H group members were invariably stronger, but nevertheless they alsoremarked that working in English somewhat hindered their work.

In distributed team work, the accuracy of documentation is even more impor-tant than in centralized work, since the participants must often rely completely

5 LESSONS LEARNED 15

on written documents. When some or all participants are not native speakers,the possibility of inaccuracy and related misunderstandings increases consider-ably. Particular care must be taken that everyone understands the terminologycorrectly. On the other hand, when the team members are aware of their ownlimited knowledge of the working language, they are perhaps more ready toask for explanations and to strive for accuracy. In our experience, establishinga glossary of the most frequently used terms, with short definitions, was a goodway of ensuring consensus. In addition, having one native speaker in the teamwas very valuable, since he could act as the definitive reference point in alllanguage questions.

In consequence of the language difficulties the groups found it indispensableto use their native languages in intra-group communication, even though theminutes of the meetings were always written in English. Hence the P groupalways used Russian in their intra-group meetings and local emails, whichconsiderably facilitated their work.

For the multilingual H group, even the local communication language wasforeign to most members. At first the students in the H group were veryconscientious to always speak English in group meetings, to ensure that no onewas sidelined from the discussion. Later on when they were more familiar witheach other, they also became more confident in using their native languages(Finnish or Spanish) when needed. They also agreed that it was very useful tohave at least one other student who spoke the same native language, especiallyin problem situations where you could first discuss your problem in your nativelanguage and then join efforts to find an expression in the common language.

Obviously all misunderstandings could not be avoided on both sides when thegroups communicated in English. But as could be expected, the students’command of the English language, both spoken and written, improved duringthe project, and they also gained more self-assurance in using it. During thesecond common working period most team members had hardly any problemsin expressing themselves. As a by-product they also learned some centralphrases and concepts in the native languages of the other team members. Thegeneral interest in the languages used within the project inspired the teamto include localization as part of their product. The customer requirementincluded only the user interface in English, but the team also implemented thecomplete interface in Russian, Finnish, and Spanish.

We feel that the question of using a foreign language should be of interest evenin industrial software development. Internationally oriented software compa-nies often use English as their working language, either because they have amix of employees with different native languages or because they have cus-tomers in many countries. In our experience, the working language skills ofthe developers in such companies may be far from comparable to native speak-ers’ skills. Software development involves complex cognitive processes that arestrongly connected to language. While software developers are usually able to

6 CONCLUSION 16

communicate in English, the accuracy and the correctness of their communi-cation suffers when using a non-native language. Typically this results at thevery least in poorly written documentation, and often also in misunderstand-ings that may be another source of delays or project failures. Therefore theneed for checking and correcting the language of the documentation shouldnot be underestimated.

6 Conclusion

In general our experience with the distributed cross-cultural student projectwas very positive. In spite of the differences in their backgrounds and thelimited time of immediate communication, the students working in Helsinkiand in Petrozavodsk formed a team and succeeded in producing a high qualityproduct within the given schedule. None of the practical problems that weencountered were insuperable, but some of them clearly require better definedprotocols, to ensure that the work of the team is not unnecessarily delayed.

The feedback from the students was very positive, and they all agreed thatthis kind of projects should be continued. Perhaps the best sign of theirsatisfaction was that they expressed a keen interest in having their productactually used for its original purpose in teaching data communication protocolsto undergraduate students. The Spanish team members also wished to takethe product with them when returning to their home university to offer it foruse in the corresponding courses.

We have plans of continuing this kind of cooperation. In the next projectwe will concentrate more on distributed work. While the joint kick-off periodand the integration session turned out to be fruitful, they also showed thata lot of time and effort in this kind of project may be spared when studentsare allowed to work as much as possible in local groups while maintainingworking communication channels and jointly agreed rules and protocols ofcommunication, documentation, and management.

Acknowledgements

We would like to thank all members of the DaCoPAn team for their cooperationas the guinea pigs of this experiment, and Prof. Timo Alanko for his valuableparticipation in planning and carrying out this project.

REFERENCES 17

References

[1] T. Alanko and Y. A. Bogoyavlenskiy. Proceedings of FDPW’97 – 98 – De-velopments in Distributed Systems and Data Communications, volume 1.Ministry of Education of Russian Federation, University of Petrozavodsk,1998.

[2] T. Alanko and Y. A. Bogoyavlenskiy. Proceedings of FDPW’99 – De-velopments in Distributed Systems and Data Communications, volume 2.Ministry of Education of Russian Federation, University of Petrozavodsk,1999.

[3] T. Alanko and Y. A. Bogoyavlenskiy. Proceedings of FDPW’2000 – Ad-vances in Methods of Modern Information Technology, volume 3. Ministryof Education of Russian Federation, University of Petrozavodsk, 2001.

[4] T. Alanko and Y. A. Bogoyavlenskiy. Proceedings of FDPW’2001 – 2002– Advances in Methods of Modern Information Technology, volume 4.Ministry of Education of Russian Federation, University of Petrozavodsk,2003.

[5] Y. A. Bogoyavlenskiy and T. Alanko. Common core of working studyprogram in computer science: Universities of Helsinki and Petrozavodsk,http://www.cs.karelia.ru/fdpw/2003/ybgv/iouri common-core.pdf.

[6] O. P. Brereton, M. Gumbley, and S. Lees. Distributed student projects insoftware engineering. In Proceedings of the 11th Conference on SoftwareEngineering Education, pages 4 – 15. IEEE, February 1988.

[7] O. P. Brereton, S. Lees, R. Bedson, C. Boldyreff, S. Drummond, P.J.Layzell, L. A. Macaulay, and R. Young. Student group working acrossuniversities: A case study in software engineering. IEEE Transactions onEducation, 43(4):394 – 399, November 2000.

[8] O.P. Brereton, S. Lees, R. Bedson, C. Boldyreff, S. Drummond, P. Layzell,L. Macaulay, and R. Young. Student collaboration across universities: acase study in software engineering. In Proceedings of the 13th Conferenceon Software Engineering Education & Training, pages 6 – 8. IEEE, March2000.

[9] M. Cusumano, A. MacCormack, C. F. Kemerer, and B. Crandall. Soft-ware development worldwide: The state of the practice. IEEE Software,20(6):28 – 34, November/December 2003.

[10] DaCoPAn. Home page, http://www.cs.helsinki.fi/group/dacopan/.

REFERENCES 18

[11] M. Kojo, A. Gurtov, J. Manner, P. Sarolahti, T. Alanko, andK. Raatikainen. Seawind: A wireless network emulator. In Proceedingsof the 11th GI/ITG Conference on Measuring, Modellingand Evaluationof Computer and Communication systems (MMB 2001), RWTH Aachen,Germany, September 2001. VDE Verlag.

[12] University of Helsinki. Department of Computer Science home page,http://www.cs.helsinki.fi/.

[13] Petrozavodsk State University. Department of Computer Science homepage, http://www.cs.karelia.ru/.

Helsinki 2004Yliopistopaino

Pikapaino