Content uploaded by Mats Daniels
Author content
All content in this area was uploaded by Mats Daniels
Content may be subject to copyright.
An International Student/Faculty Collaboration:
The Runestone Project
Mary Z. Last
St. Edward's University
Austin, TX
last@acad.stedwards.edu
Vicki L. Almstrum
University of Texas at Austin
Austin, TX
almstrum@cs.utexas.edu
Mats Daniels
Uppsala University
Uppsala, Sweden
matsd@docs.uu.se
Carl Erickson, Bruce Klein
Grand Valley State University
Allendale, MI
{erickson, kleinb}@csis.gvsu.edu
Abstract
Students of today need to be prepared to work in globally
distributed organizations. Part of that preparation involves
teaching students to work effectively in teams to solve
problems. Students also must be able to work with
individuals located at distant sites where there is no or very
little face-to-face interaction. The Runestone project, an
international collaboration between two universities, adds
new dimensions to student teamwork, requiring students to
handle collaboration that is remote, cross-cultural, and
technically challenging. Runestone is a three-year project
funded by the Swedish Council for the Renewal of
Undergraduate Education. A pilot study in 1998 was
followed by a full-scale implementation in 1999 with
another implementation ongoing in 2000.
Each time this global cooperation project is run, both
students and faculty learn important lessons in how to work
with each other in a virtual environment. This paper
discusses both student and faculty learning outcomes for
Rnnestone 1999.
1 Introduction
The Runestone project involves students and faculty at
Uppsala University (Sweden), and Grand Valley State
University (Michigan, USA), and researchers from the
Open University (UK), the University of Kent (UK), and
the University of Texas at Austin (Texas, USA). The
Permission to make digital or hard copies of all or
part of
this work
for
personal or classroom use is granted without fee provided that
copies are not made or distributed
for profit or
commercial advan-
tage and that copies bear
this notice and the full citation on the first
page.
To copy
otherwise, to
republish, to post on servers
or to
redistribute to lists, requires prior specific permission
and/or s fee.
ITiCSE 2000 7/00 Helsinki, Finland
© 2000 ACM 1-58113-207-7/00/0007...,$5.00
project's primary goal is to introduce international
collaboration into undergraduate Computer Science
education in a way that has value for all participants. A
research goal for Runestone is to identify effective support
structures for remote international collaboration, including
strategies for communication, project management, and
technology use [1]. The Runestone project joins a growing
list of research projects [2, 3, 4, 7, 8] that are investigating
ways in which international collaboration can be introduced
into the computing curriculum.
2 Learning Objectives
Tearn-related learning objectives for students in the
Runestone project include developing software solutions in
a team environment, providing international contacts and
experience working in a team with people from a different
culture, preparing students for the possibility of working on
global teams, encouraging peer learning, and providing
experience with working in a team with people having
dramatically different educational backgrounds.
3 Runestone 1999
The Runestone 1999 implementation required students at
Uppsala and Grand Valley State University (GVSU) to
work together on the Brio project (described below). The
Runestone research team included two faculty coordinators
(one from each institution) directly responsible for the
course; a researcher responsible for student data collection
(background questionnaire, project logs, IRC logs,
journals); a researcher responsible for small archives; a
researcher responsible for faculty data collection
(interviews at both the beginning and end of the
implementation); a research coordinator; and the
department chairs at both universities. The research team
met in June 1998 in Uppsala and in October 1998 in
Michigan to plan the Runestone 1999 project. Additional
planning activities were done via email correspondence.
128
3.1 The Brio Project
The technical problem that was specified for the globally
distributed group project was designed to meet the
Computer Science capstone course requirements for the US
students and the project portion of the course requirements
in Computer Systems II for the Swedish students. This
project involved designing and implementing a distributed,
real-time system to navigate a steel ball through a board by
tilting the surface of the board via positioning motors. The
board and ball are a modified version of the weU-known
Brio Labyrinth game. A monochrome digital video camera
focused on the board aids the computer in navigation. The
user interface is presented through a web browser. Naive
users who play the game specify a path for the ball to
follow, and then get feedback on the result of their run.
Users who are programmers may more actively participate
in the game by writing, compiling, submitting, and finally
running code to navigate the ball through a specified path.
The Brio project has elements of real-time control (the Brio
game), low-level distributed systems (multiple CPUs to
gather data, drive motors), and high-level distributed
systems (web interface, network prograrnrning), in addition
to some demanding requirements on the language used to
implement portions of the project (dynamic code loading,
security). A complete description of the Brio project can be
found at http:llwww.csis.gvsu.edulclasslbrio119991.
3.2
Role of Faculty
There were two faculty coordinators responsible for the
Runestone project, one at each university. A single faculty
coordinator evaluated all students on a particular team. The
US faculty member was responsible for teams with a US
team leader and the Swedish faculty member was
responsible for students in teams with a Swedish team
leader. The faculty coordinators corresponded with students
via email and class information was posted to the project
website. The coordinators also held Interact Relay Chat
(IRC) office hours and, when invited, participated in
student team meetings on IRC. The faculty coordinators
were conversant in both Swedish and English.
Students were instructed that all interactions with their
faculty coordinator should be done electronically. A
challenge was rnim)aaizing the amount of face-to-face
contact that local subgroups had with the resident faculty
coordinator.
3.3 Student Demographics
Forty-two students (21 from each school) participated in
Runestone 1999. Seven teams of six students (3 students
per institution) each worked on the Brio project from late
January through the end of March 1999. Of the 42 students,
only five students were female (4 from the US and one
from Sweden). Within their own institution, students self-
selected teammates.
Each team had one team leader and the remaining students
on the team were assigned the role of developer. Faculty
coordinators clearly defined the responsibilities of each
role. Half the teams had a US team leader and the other half
had a Swedish team leader. Two teams had female team
leaders. Team leaders were elected by the local subgroup,
that is, for half of the teams, the US subgroup elected a US
team leader and for the other half, the Swedish subgroup
elected a Swedish team leader. The faculty coordinators
arbitrarily paired the local subgroups to form teams.
The project required students to program their solution
using both C and Java. Swedish students were more fluent
in Java, while the US students had more experience in C
programming. US students were juni°rs3°ra seniors (3 ~d or
4 th year) and Swedish students were year students.
While all of the students were at approximately the same
stage in their academic programs, the Swedish students
were slightly older than their US counterparts because
Swedish students start their university studies at a later age.
3.4 Computer-Mediated Communication
Students used Internet Relay Chat (IRC) for team meetings
and corresponded with each other regularly via email. All
communication was conducted in English. At the beginning
of the project, students used individual web pages to
introduce themselves. Each team designed a team web page
and used the web to make project documents available to
all team participants. Students archived all email and all
IRC logs. These archives were not available to faculty
coordinators during the duration of the project.
3.5 Additional Student Data
Faculty and researchers involved in the Runestone project
are interested in both the product and the process. As part
of the research design, students were asked to provide
additional data related to the process. None of the
additional data was made available to the faculty
coordinators during the project. Because students could
earn points toward their final grade by simply completing
the additional requirements, faculty coordinators were
notified only that a student did or did not complete
questionnaires, project logs, and journals. Approximately
90% of the students completed the additional data
requirements. No student complained about the extra work
involved.
At the beginning of the semester, students were asked to
complete a background questionnaire. The questionnaire
measured the students' comfort level with computer-
mediated communication as well as their attitude toward
group work and their awareness of foreign culture. Students
also were polled about other demands on their time, such as
other course work and employment. The questionnaire can
be found at http:/Iwww4.gvsu.edullastmlrunestone.htm.
During the project, students completed project logs that
focused on the amount of time spent on the project,
whether the work was done individually or in a group, and
the type of media used. The project work log can be found
at http:llwww4.gvsu.edullastmlrunestono time_logs.htm.
129
Students also completed three electronic journals, one at
the beginning of the project, one in the middle (after a
major deliverable), and one at the end of the project. For
each journal, students had to respond to questions that
addressed team process. Students were assured that the
faculty coordinators would not see their journals. Many
students used the journals as a way of expressing
frustration with various components of the project. The
journal questions can be found at
http://www.csis.gvsu.edu/class/brio/1999/joumal/.
3.6 Student-Identified Obstacles
In the final journal, students were asked to reflect on the
project and identify major problems. The team-related
problems that students identified, in order of decreasing
importance, were poor communication, member non-
participation, poor leadership, lack of technical skills,
procrastination, and differences in motivation.
Of the problems cited, many are common to all student
teams. For example, Poumaghshband [6] reports that more
than 50% of students in single-institution courses that
include team projects reported problems with items 1, 2, 3,
and 5. It is likely that some problems are amplified due to
the global distribution of the teams. Each of these
problems is expanded in the remainder of this section.
While the problem of poor communication is a "catch-all"
term that can be used indiscriminately, students in the
Runestone project had very specific concerns. These
concerns were similar to those reported by Macek et al [5]
in another study of international teams. Students were very
critical of anyone who failed to respond to email messages
in a timely fashion. While students liked the flexibility of
IRC, they also felt that it was, at times, an obstacle. One
student commented:
Having only a text based mode of communication
made it hard to read how everyone was feeling. If
one person was feeling frustrated for some reason,
he would read that into everyone else's comments as
well. If someone were feeling pretty good, he might
assume everything is free, and miss subtle clues.
Another obstacle to good communication occurred when
one student of a sub-group spoke collectively for the group
during IRC sessions. One student commented:
When talking on IRC they usually used one
console with an assigned typist. I'm sure a lot was
said by them that never got typed.
Anecdotal evidence from past projects shows that member
non-participation is often a problem in courses requiring
teamwork. It was no different in a globally distributed
team. However, too much participation was also a problem
for students. In a few instances, team members were so
anxious to do a good job that they made changes to
software that was not their responsibility. Other team
members perceived this behavior to indicate a lack of trust.
Poor leadership was evidenced when team leaders failed to
keep people on task and were negligent in communicating
deadlines and changes to requirement specifications. The
obstacle of "lack of technical skills" seems to be directly
related to the multi-institutional aspect of the course. The
different educational backgrounds of the students presented
problems for some teams, requiring students with better
technical skills to do more work. As one student
commented, procrastination "is a golden oldie", causing not
only frustration among team members but also lessening
the degree of trust they placed in the team member's
performance.
The obstacle of "differences in motivation" showed up in
the opportunity for the team to earn extra credit. Some team
members were disturbed when other members did not seem
motivated to try for extra points. One student commented:
I do think I had the technical skills but was held
down by the rest of the team because they didn't
want to go for all the bonus points.
3.7 Other Obstacles to Running International
Collaboration Projects
The results from Runestone have pointed out some general
obstacles to running international collaboration projects,
including time zone difference, symmetric assessment
criteria, and mismatch between course stop and start dates.
The six-hour time difference was a problem for real-time
communication. Some teams varied meeting times to make
getting together as a group more equitable for all
participants. In one team that did not vary the meeting
times, a Swedish student refused to participate in IRC
because "I am not a night person."
Discrepancies in assessment criteria between the two
institutions was a serious obstacle. In Sweden, the project
grade was only a portion of the fmal grade students
received for the course. In the US, the project grade was the
course grade. Also, the US grading system had more finite
gradations (A, A-, B+, B and so on) than the numerical
Swedish system (5, 4, 3, Unsatisfactory). The faculty
coordinators had to consider both assessment criteria when
evaluating students.
The short project duration (10 weeks) was the result of
course semesters that did not match. GVSU's semester
started two weeks before the Swedish term began; the
Swedish term ended in the middle of GVSU's semester.
4 Conclusion
While there were problems with the Runestone 1999
implementation, the student learning outcomes made it
worthwhile. These learning outcomes, as identified by the
students, include learning how to work collaboratively with
others, how to consider different ideas and compromise on
a solution, how to integrate the various project pieces and
130
produce a working product, and that there are similarities
as well as differences between cultures.
A primary challenge in international project courses is in
course management. International project courses require
extensive faculty coordination to determine grading
policies, course pre-requisites, project scope, and project
supervision. Students encounter many of the same
problems in an international team that they do in a local
team.
The two universities are continuing Runestone in 2000 and
are actively seeking to promote international collaboration
with other universities. The project challenged the students
technically and helped them appreciate the need to learn to
work with others.
4.1 Faculty Observations
The faculty coordinators noticed two items of particular
interest related to team process in an international setting.
First, students were hesitant approaching faculty
coordinators with problems related to their team members
and member participation. Second, the teams where
students permitted themselves to have healthy conflict with
both their local and remote teammates seemed more
productive.
In the Runestone 2000 implementation, faculty
coordinators hope that more frequent deadlines with
smaller deliverables will allow dysfimctional teams to be
recognized more quickly. They also hope that more
frequent deadlines with smaller deliverables will provide an
opportunity for students to disagree with each other sooner
and move past conflict to cooperation.
4.2 Advice from Students for Students
In their final journal entry, students were asked to provide
practical advice to students doing the project in 2000. This
advice was directly related to what the students perceived
to be the major problems with the project. The advice
students gave most frequently was to communicate, not to
procrastinate, to get to know everyone on the team
irnlnediately, to distribute the work load evenly, to allow
plenty of time for testing, and to take action quickly when
team members don't perform.
4.3 Advice from Students for Faculty
Students also had advice for faculty running international
collaboration projects. Faculty coordinators have
incorporated many of these suggestions as part of the
project run during the Winter 2000 term, including
consistently responding to email quickly, providing more
feedback on design issues, establishing a procedure for
informing students when there are changes to specifications
and/or schedules, providing guidelines on student roles in a
team, providing more frequent intermediate checkpoints,
allowing students to have more input into the team leader
decision process, and providing feedback on individual
performance early in the semester.
4.4 Closing Thoughts
The following comment from a student is representative of
how the majority of the students viewed the project:
It was a very interesting project. A good test of our
skills as overall programmers and people. To have
to communicate with people you will never meet
face to face and integrate hardware and software
was quite challenging but also very rewarding when
it worked at the end.
5 Acknowledgements
The Swedish Council for Renewal of Undergraduate
Education sponsors the Runestone project. A very special
thank you goes to all the students who participated in the
Runestone pilot project and Runestone 1999 for sharing
their thoughts and ideas.
References
[1] Daniels, M., Petre, M., Almstrum, V., Asplund, L.,
Bjorkman, C., Ericskon, C., Klein, B., and Last, M.
Runestone, an International Student Collaboration
Project. Proceedings of IEEE Frontiers in Education
Conference, Tempe AZ. November 1998.
[2] Jarvinen, K., Pienimaki, T., Terasvirta, T., Kyaruzi, J.,
and Sutinen, E. Between Tanzania and Finland:
Learning Java Over the Web. Proceedings of the 30 th
SIGCSE Technical Symposium, SIGCSE Bulletin,
31(1), March 1999, pp. 217-221.
[3] Knoll, Kathleen and Jarvenpaa, Sirkka. Learning to
Work in Distributed Global Teams. Online. Intemet.
[August 3, 1995]. Available WWW:
http://uts.cc.utexas.edu/-bgac313/hicss.html
[4] Knoll, Kathleen and Jarvenpaa, Sirkka. Learning to
Work in Distributed Global Teams. Online. Internet.
[January 10, 1998]. Available WWW:
htttp://www.bus.utexas.edu/-jarvenpaa/gvt/gvt98/hicss
.html
[5] Macek, Tornas, Mannova, Bosena,, Kolar, Josef, and
Williams, Barbara. Global Cooperation Project in
Computer Programming Course. Proceedings of the
30 th SIGCSE Technical Symposium, SIGCSE Bulletin,
31(1), March 1999, pp. 208-211.
[6] Poumaghshband, Hassan. The Students' Problems in
Courses with Team Projects. Proceedings of the 21 st
SIGCSE Technical Symposium, SIGCSE Bulletin
22(1), February 1990, pp. 44-47.
[7] Spargo, Lois and Kelsey, Barbara. How Two
Universities Crossed the Border. Online. Internet.
[January 12, 1999]. Available WWW:
http://www.mai-freiburg.de/inet96/c8/c8_ l.htm
[8] Yoo, Youngjin. An Investigation of Group
Development Process in "Virtual" Project Team
Environments. Online. Internet. [November 19,
1996]. Available WWW:
http://www.bus.ute xas.edu/~j arvenpaa/yoo.html
131
