Meeting



previous << Tutorial Track >> next
At each meeting the whole team and its team leader get together. The team leader is the motivator and when required a moderator. Occasionally he is an expert.

A meeting takes approximately one and a half hours. During the meeting five well defined activities take place. It is important to note that in the first few meetings these activities are viewed as sequential steps that define a workflow. Once students are used to the meetings activities should be carried out in parallel. In this way, the mutual dependencies between the activities are exploited to improve the outcome. However, the workflow technique may be used if teamwork gets stuck. For better understanding activities are presented as workflow steps here and that is the way they should be explained in preliminary teaching.

First, the results of the previous week's effort are discussed and validated. Then the team concentrates on finding new tasks. Task planning is artifact oriented. The main question is - what has to be done next in order to contribute most effectively to the growth and the quality of the artifact sets? Brainstorming techniques are very helpful. All suggestions must be taken seriously and gathered for further discussion.

Usually more work is found, than is possible to do during the following week. Therefore the tasks have to be sorted with respect to their importance. Based on their current knowledge and opinions the tutees discuss what to do next and why they should do it. The result of this activity is a task list, ordered by importance. In this way the students learn to appraise the relative importance of the mutually dependent families of software engineering activities.

Alternative solutions for the tasks are suggested, discussed and finally one of them is chosen for each task. Tasks that are too large to be carried out by a group in a week have to be split into several tasks. In the end every task is assigned a new, succinct title and a short, nonetheless precise, description. The students estimate time required for each task on the ordered list. The team decides which tasks have to be completed during the next week.

Tasks then have to be assigned to team members. Usually a task is assigned to a group of two to four participants. The group members reestimate the time that is needed to carry out the task and agree how much time every member plans to contribute. Tasks that cannot be assigned are considered the following week. The team is divided into small groups that work on tasks. This division is not static and at each meeting, new groups are formed. The tutor has to monitor the selection. In a project threads of strongly dependent tasks exist. If a task has a predecessor, it should be assigned to the predecessor's group but at least one group member should be replaced with a new team member. This concept of small and frequently changing groups is crucial, because we pursue a generalized notion of collective ownership. It is the target of the exercise that students learn about the overall structure of the system that is built up. Ideally, every student should have an understanding of every technology and concept used in the project, and how they interact. Consequently students do not over-specialize and the learning outcome is shifted in the direction of high-level hard skills and soft skills.

At the next meeting results are evaluated. The students talk about their experiences and describe problems that occurred. Finally, every student tells how much time they worked. The team has to agree on the time each student can add to his or her working time account. Students have to work a fixed total number of hours. Independent of the total outcome of work we find students typically are willing to respect the work of other, even perhaps less experienced, students. Our approach tackles the problem that the students often do not trust the industry of their colleagues because they have different capabilities - a potential source of squabble. The overall teamwork can be supported by appropriate simple tools e.g. repositories, mailing lists and discussion forums.

previous << Tutorial Track >> next