|
While in university, students are told that they must do their own work
and not copy others’, and that they must work as individuals. However
in industry, most software projects are not individual efforts, but are
accomplished by teams of qualified professionals. This is because of the
size of soft-ware projects and the link between teams and performance.
Katzenback and Smith noted in The Wisdom of Teams: Creating the High
Performance Organisation that “teams out perform individuals
because they bring together complementary skills, create a situation where
problems are solved more quickly, provide a social framework for working,
and create a fun atmosphere in which to work”.
To better equip our students for working in industry, we, at the School
of Mathematical & Computing Sciences at Victoria University (Wellington,
New Zealand), run a semester software engineering project course in which
the students work in teams. We realised only recently that we were asking
our students to work in teams without taking into account that they have
had little experience of team work. As of 1997, we restructured the team
work component of the course. To facilitate the team process, we now provide
both direct and indirect support mechanisms.
Directly Supporting Team Processes
We directly support the team process by providing details of the experiences
of previous students and presenting a lecture about team work. Teams can
learn from the experience of others, especially when that experience is
very close to their own. At the end of the course, students write an essay
on ‘Managerial Lessons Learned’. We put the essays on the
web and ask current students to read the comments of past students.
Teaching students about the team process makes them aware of some of
the difficulties they can face when working in a team. During the first
half of the lecture, we cover how to set realistic project goals, wisely
allocate tasks to team members, run meetings, manage time, and communicate
and manage shared group documents (like meeting minutes and design specifications).
We also describe the roles of both team leaders and team members. An invited
speaker who has extensive experience with teams in industry and academia
conducts the second half of the lecture, giving a talk entitled, ‘When
Group Work Doesn’t Work: What to Do About It’. Besides addressing
problem areas, the speaker shares his methods for creating ‘energised’
groups. This lifts the discussion about the team process away from problems
to rewards.
Indirectly Supporting Team Processes
We indirectly support the team process by providing timely technical
assistance and the framework in which the teams are to work. Technical
support is available from school programmers and a dedicated tool assistant.
The programmers ensure that the programming environment is operational
and both the programmers and tool assistant give tutorials about tools
that are available to the teams. The tutorials are carefully timed so
tools are introduced before students require them.
The process guidelines, stated clearly at the beginning of the course,
include due dates for major documents and a marking scheme. The marking
scheme rewards individual contributions to the team process, encouraging
all team members to contribute to their team.
We define the team structure and provide each team with a client and a
supervisor. An expert in the project domain, the client clarifies project
requirements and resolves ambiguities as they arise. The supervisor acts
as a mentor that guides, motivates and provides feedback to the team.
Teams are required to choose a team leader.
A questionnaire that asks students to list their preferred team mates,
skills and work habits is used in team formation. Based on the feedback,
we assign students to teams. Similarly, students are asked to select their
preferred project from a list of available projects. Providing a list
of projects, rather than allowing teams to propose their own project,
helps the team get down to work more quickly. The projects usually require
students to develop software that is useful to someone in our school.
Teams are more motivated if they are working on a project they are interested
in and if the resulting software product has potential real use. We allow
more than one team to work on the same project so no team is given preference
over another when projects are allocated.
Conclusion
Students have found our course to be rewarding but exhausting. These
comments (both positive and negative), from the essays on ‘Managerial
Lessons Learned’, summarise the course experience for some students:
“All the hard work pays off...in the long term... I
enjoyed the course very much and believe that a lot of that had
to do with what the team and I made of it and put into it.”
“[This course] will probably be the most stressful,
headache inducing, time consuming, sleep depriving, rewarding, interesting
and useful course you will ever do.” |
The course has been valuable to the students in many ways, but students
often cite the team experience as being the most rewarding part of the
course.
“I have learnt a lot from doing this course. Most of
all, I learned a great deal about the management aspect of team
work.”
“The primary value of this course is not in the credits
at the end of a semester. Its value is reflected in the exposure
you receive to software project development in a team environment.” |
Almost all students make some comment about the value of having a team
leader. This occurs even in a team where the team leader does not show
strong leadership abilities.
We also carry out surveys at the mid-point and end of the course. Our
main finding so far have been that: (a) learning to work as a member of
a team is a necessary skill for computer science students; and (b) teaching
and supporting the team process, both implicitly and explicitly, provides
a better learning environment for the students.
References
- Katzenback, J.R. & Smith, D.K. The Wisdom of Teams: Creating
the High Performance Organisation. Boston: Harvard Business School,
1993.
- Gersting, J.L. & Young, F.H. Content + experience = curriculum.
Proceedings of the twenty-eighth SIGCSE (Special Interest Group in Computer
Science Education) technical symposium on computer science education,
1997, pp. 325-329.
- Proulx, V.K., Richard, R. & Fell, H. Foundations of Computer
Science: What Are They and How Do We Teach Them?. Proceedings of
the conference on Integrating Technology into Computer Science Education
(ITiCSE), 1996, pp. 42-48.
- Villarreal, E.E. & Butler D. Giving Computer Science Students
a Real-world Experience. Proceedings of the twenty-ninth SIGCSE
(Special Interest Group in Computer Science Education) technical symposium
on computer science education, 1998, pp. 40-44.
Dr Dobbie was a Visiting Scientist at NUS’ School of Computing
(1 December 1999–31 January 2001).
|
