Teaching Team Skills in  Introductory Software Engineering Courses

Abstract

 We base our software engineering units on Craig Larman's popular UML-based methodology, RPM, but also provide discussions on the need to choose the best models for a given domain and switch the order in which they are carried out. As an example of this kind of thinking, we introduce OMT 98 , which provides a sensible alternative to RPM for database intensive applications.

 Incremental maintenance sounds redundant. The point is that iterative incremental methodologies will  increasingly have to come to grips with traditional maintenance issues. In order to introduce our students to these issues, they have to develop increments for a software which is now well into its second year of development by a third cohort of students.

 The most challenging strand, at least for the teachers, is building team skills. By enlisting the help of the Department of Behavioural Science and Technology, we are putting to bear multi-disciplinary expertise on topics such as team development stages, task and group maintenance functions, leadership styles, roles, effective management of team meetings, risk management, task planning and tracking, conflict management and effective performance feedback.

The talk will touch on the first two strands, focus on the third strand and introduce some of the preliminary results of the course, comparing it to previous software engineering courses, which covered the strand in less depth.

A preliminary version of this paper was presented at the 2nd Annual Watts Humphrey Lecture Series, Software Engineering in the 21st Century, Atlanta (November, 2000).
 

Introduction

Industry reports admit that, in spite of dwindling university resources, the technical level of USB graduates is still extremely high and up to date and their ability to work under pressure second to none; nevetheless they also increasingly complain that, in general, the graduates:

• Are  not good team players,
• Have very little feel or interest for company goals,
• Tend to be overconfident, overoptimistic as regards project effort estimation and late in project delivery.
• Tend to adopt new technologies recklessly, with little or no risk and cost assessment,
• Prefer to start, or restart, development efforts from scratch, especially if they had not participated in the earlier development efforts.

1999 was a busy year for teaching staff, as USB increasingly transitioned its courses --including software engineering-- towards object-oriented technology. The software engineering courses also began to take a hard look at project management issues, and it became increasingly obvious that student teams were encountering significant team-related difficulties which they seemed unable to overcome even with instructor intervention. Many of the industry complaints clearly showed up during course projects. By the end of the year, an emerging consensus pinpointed lack of team skills as the most critical barrier to future improvement. It was also obvious that none of the departments traditionally associated with the Computer Science programme possessed the knowledge, training, skills or experience to  teach effective teamwork properly.

In the first semester of 2000, the Department of Behavioural Science and Technology (DBST) presented a twenty hour training seminar on creating and maintaining highly effective teams for 15 members of the Department of Computer and Information Technology (DCIT) . As a result of the success of this seminar, the DBST agreed to  strengthen its collaboration by co-teaching three optional software development courses: one used to prepare USB student teams for the ACM Programming Contest, one to design virtual classroom software and the first term of the optional two term Object-Oriented Software Engineering course. In this presentation we will focus on this last course.
 

A three strand Software Engineering course

The introductory Software Engineering course is closely based on Craig Larman´s Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Prentice-Hall, 1998). The book introduces an incremental iterative development approach, based on planning and elaboration, analysis and design phases and use, conceptual, and object-interaction models represented with UML use case, class, system sequence and collaboration diagrams plus event reaction contracts. After attempting different team sizes, we recommend that for this first team-based course, students work in teams of 4-5 members on 1-2 KLOC projects. The course tends to focus more on the modeling techniques associated with object-oriented software engineering, ignores maintenance issues altogether and introduces some basic project management activities such as planning, control and follow-up, group discussions, task distribution, risk management and scheduling. Students are required to adopt team roles such as project leader, webmaster, technical editor and meetings coordinator. Currently, the course instructors typically provide a few tips on these activities and leave the students to learn by carrying out the required activities; next year we plan to provide a more systematic introduction, possibly incorporating some PSP and TSP  recommendations.

This year, the optional two term course on OOSE has tackled the three strands we have identified. In the first term it delves more deeply into object-oriented design issues, grapples with the maintenance issues that arise when they are forced to develop increments for a pre-existing 8KLOC software which is now well into its second year of development by a third cohort of students, and undergo multidisciplinary training in effective team building and maintenance skills by DCIT and DBST staff.

During the term approximately twenty six out of the seventy contact hours planned for the course, were devoted to learning about effective teamwork and project management. The DBST staff conducted nine two hour sessions on effective teamwork, while DCIT staff devoted  an additional eight contact hours to topics closely related to teamwork or project management. The thirty four students who took the course split into three 10-12 member teams starting from the second week of the course. The teams remain stable for the remainder of the two terms and work together in all team sessions.

A typical teamwork session will concentrate on one topic such as effective team communication. The teams will generally carry out two supervised team exercises in  a session; the first exercise tends to be more in the nature of a game, thus allowing a more relaxed learning environment and creating more opportunities for team bonding, while the second exercise generally applies and deepens their newly gained knowledge to a real problem the team has to face and solve during  software development. In both exercises, teams receive feedback on their experience, both from instructors and, occasionally, from members of the team chosen as observers for the duration of the exercise. This allows the team members to develop the ability to take a step back and study team processes.

DBST staff conducted sessions on the following topics: Introduction to group and team processes, building and maintaining hightly effective teams, leadership styles, team problem solving, team planning, team communication with particular emphasis on how to provide effective feedback between members, stress management and differences and conflict management. The ninth session on team decision making was conducted by a DCIT member supervised by DBST staff.

DCIT staff further covered topics such as the use of time record logs, team roles (project leader, architecture and design coordinator, docmaster and configuration manager; all four roles also have an understudy), conducting meetings (use of agenda, time management, proper closure), risk management, function point and COCOMO based estimations, team and peer assessments.
 

Course risk factors

• Cultural differences between DCIT and DBST staff.

This risk was considerable lessened by having planned and held the DCIT training seminar well in advance of the course, and by having both DCIT and DBST staffs discussing each weekly session before execution.
 
• Topics overload.

 
• DCIT staff did not have sufficient expertise in software maintenance to warrant the inclusion of this third strand at this stage of the game.

In particular we overestimated the quality of the documentation associated with the software to be maintained. While this is an (unfortunately) common real-life situation, it jeopardizes the learning situation, since one already has to contend with a prejudiced student attitude towards maintenance.
 
• Too many students

The course was originally planned for 16-20 students which would split into two teams. We underestimated the demand for the course. We have had all sort of problems related both to the size of the teams and the number of students in the course, including lack of a classroom with proper acoustics for simultaneous 3-team discussions; as observers we found we simply were not hearing a great deal of what was being discussed. Based on this experience, we would recommend such a course start with no more than 16 students (which would split into two teams) and build up to twenty four students (which would split into three teams) in future offerings.
 
• Lack of CASE tools, due to the university's  severely constrained financial situation.

 

Results

1. It is clear that DCIT staff members feel much more comfortable with the material by having DBST support.

 
2. Students seem to enjoy and look forward to their weekly teamwork sessions.

 
3. We strongly suspect that skill transference can be improved. In particular, when the teams carry out actual project work, they tend to focus on the task at hand and exclude many of their newly acquired skills. It may well be the case that they require more time to digest and visibly start applying these skills. It could equally be the case that the mental gap between a stress-free gaming exercise and a stressful work situation exercise is too large and needs to be better bridged.

 
4. This year's course emphasizes building highly effective teams. In practice this means they are built to be more autonomous and independent of the course instructors. Teams are graded basically according to quantity and quality of their artefacts, but it is hard to detect individual contributions or dysfunctions, especially in a culture, like the Venezuelan, which tends to protect the individual from outside forces even when the individual in question is clearly and consistently falling below the team's minimum performance norms and threatening the team's grade. We have adapted EPCoS' yellow/red card bundle, both toning down its harsh penalizations and adding a complementary  incentives mechanism. Even though the penalization is often, and jokingly, threatened, it has never been carried out. Incentives have been applied twice.  The team cover up of  individual performance is particularly disturbing to DCIT staff members.

 
5. Weekly time record logs include items to grade on a five point scale, the individual member's motivation and satisfaction with his work for that week. This has been a key and invaluable feedback mechanism for the instructors and we recommend augmenting PSP weekly time logs with it.

 
6. We expected that reporting total time spent on activities would be very much of a cultural shock. It turned out more smoothly than we expected, with the important exception of time spent in meetings. Teams reported only how long meetings lasted and "forgot" to add up all their members' participation time.  For example, they would report a 8 to 9 a.m. meeting between  twelve participants as having taken up one hour and fail to indicate that it had actually  consumed twelve people-hours. This was done in spite of repeated written and verbal injunctions to the contrary. The individual time record logs allowed this mistake to be caught. While initial excuses focused on their ignorance of proper procedure, one group finally admitted that they felt they were unfairly inflating billed time! It is also possible that the grading procedures students are used to, which encourages them to produce artefacts in less time and penalizes them for additional time and their keen and sometimes prejudiced sense of time "wasted" in meetings lead them to prefer to report what they call "productive hours".

 
7. The course has involved a lot of effort, but it is fascinating!