What "process instruction" should instructors give students when assigning a team project?

I am in some ways a poor person to answer this, because this is something that I've struggled with. There was one recent lab where I was quite successful, though, and I leave it here without any promise of generality:

Most recently, when assigning a very hard lab, I pointed out that divide and conquer was a silly approach when the coding assignment is intellectually challenging. (In this case, students were making a Lambda Calculus REPL and interpreter/solver).

Dividing the task up is a way to ensure that no one fully understands what the other person did, because each stage is tremendously complex. The end result would be labs that never actually came together and functioned, and no one on the team able to understand exactly why it wasn't working.

I explained this, and pointed out as well that pair programming is a way to make sure that there are two sets of eyes on these intricate pieces, and two brains engaged to make sure that both the problem and the solution (both difficult in their own right) ultimately made sense to everyone.

This worked extremely well. I don't think that any group divided the work, and certainly not in any substantial way. (There may have been brief periods of independent work while a student was absent, for instance, but that is unavoidable in the structure of my school.)

It is also worth noting that almost all of the labs came in working, and from my code interviews, it was clear that each student understood well what that had done, so that is further evidence that there was little dividing of the work going on.

Before you assign students their first team project some instruction is needed. You can't assume that they will understand teamwork any more than that they will understand recursion without instruction.

But first, you should decide on how you want their teams to behave. In this answer, I'll consider only a team structure that requires a team leader who will assign tasks and be responsible for the overall project, including the integration of the pieces done by the various team mates. This is only one of many possible team structures but here I'll stick to just this.

If this is the team structure you assume will be used, don't assume that it will just happen and coalesce without your efforts at the start and throughout. Among other things they are too likely to spend far too much time at the start on organization, leaving too little for the actual work.

The first consideration is to decide on both the teams and on how the leader is to be chosen. You can force it a bit by choosing the leaders yourself, assuming that the scale of things permits it and you know something about the students. One way that I had success with in such a situation is to use a round-robin sandlot baseball method. I would choose the leaders/captains and the captains would alternately choose team members until everyone was chosen. This assumes that the students know one another generally.

Teams can choose their own leaders, also, perhaps via an election. But make sure that the choice is made immediately and that you learn who the leaders are.

Alternatively you can choose the teams yourself, either randomly or using some knowledge you have of their abilities. It is probably a mistake to let teams just coalesce into groups of friends as things are likely to be too lopsided in many ways. You want the better students distributed around the teams as well as the strugglers.

This structure is asymmetric, with a few students, the captains, having a special role. Let them know that "equal participation" isn't the same thing as saying everyone does the same thing. People can contribute differently to a successful programming project, with some doing most of the programming, others writing user manuals, others doing research or testing. But they will need some instruction on the kinds of roles and the leaders will need some instruction about how to assign roles (or take volunteers) for the various tasks.

Let the leaders know that their job is primarily coordination and communication (with you). Encourage them to have frequent meetings with their teams, and constant feedback if there are any problems. Let the leaders know that flexibility is needed and that some members who take on a task will need help in completing it. Make sure that the leader make allowance for such things.

One way to communicate all of this to a team is to give them a few descriptions of projects that succeeded and a few that failed, with an explanation of why. Horror stories to help them avoid the most common pitfalls. And one of the big pitfalls is not having adequate time for integration of individual efforts. It isn't going to all fall together in the last few hours. Emphasize that.

And, since the team members will play different roles in the project, give them a "role book" that describes how to carry out one's own role and interact with others. But everyone should know not only their own role but that of others as well.

One of the big lessons that some of them, at least, won't have understood, is that it is a learning experience, not product development. Students can learn even if a project doesn't really build much. Put the emphasis on learning, not getting over a finish line on an arbitrary (and possibly too short) time scale.

Another thing to communicate to the captains is that if trouble arises you need to learn of it immediately. Perhaps the project needs refocusing or rescaling. Perhaps the captain will need help in dealing with a non-participant. And if you have frequent meetings with the captains (perhaps in a group) you can feed them "management" hints for the teams.

One way to have meaningful meetings with the captains is to do it with the entire class present. You and the captains discuss issues while the others listen and take notes. These can be quite short meetings if the scale is small enough, say five or so teams.

Part of the instruction of the teams, perhaps through the leaders, is to encourage team members to help one another whenever needed. A team project isn't just the sum of a bunch of individual projects thrown together.

If you intend to use peer evaluation at the end of the project, make sure that they understand that at the start. In fact, it is best to give them details, such as what precise form it will take. My own preference is to have people say positive things about the most productive members rather than to rate or grade everyone. I also require a self evaluation along with any peer evaluation: "What was your chief contribution?".

---

Note that this style of project is not my favorite, but it is for many.

There is another way to organize a team project that is most appropriate if there are only one or two teams and the course is mostly about completing a large project. The compiler course or a "senior" capstone course often has these characteristics. This is the Agile Software Development approach. It requires a lot of instructor inputs, though fewer at the beginning.

Note that I'm assuming in this that the scale is reasonable. If the class is too large it will be hard to manage this unless there are enough TAs already proficient in the process. That may be an unreasonable assumption for many.

In an Agile Software Development project, a team is self directed but acts to satisfy requirements made by a "customer" who provides the requirements incrementally in the form of short "stories", mostly representing features. The customer also needs to accept work as it is done (or reject it) and can redirect the project at frequent intervals (iterations).

Here the instructor (or perhaps a TA) acts as customer and provides a set of short development stories and prioritizes them for development. The stories can change as the project progresses and the stories themselves can be changed and added to. The project works in short cycles. A story should be small enough that a pair of students working together can complete it in a week (or, perhaps a day if a flipped classroom is used).

Most agile teams also need a "coach" to get them started and to help them learn the various agile practices such as paired programming and test first development. The instructor, or a TA, serves also as the coach.

Here the initial instruction about process can be done as a demonstration where two people, perhaps the instructor and a student pair program to develop and test a few simple stories. The instructor carries on a dialog about what is happening and only a few practices are used. It is actually best if the second person is already proficient in the process so that roles can be switched as needed between the "driver" who writes the code and the "navigator" who gives guidance.

Agile development works well in a classroom situation if there is time available each "iteration" for a retrospective on the work done so far by the team. This is the point at which the instructor can comment on process and where it works and doesn't, as well as the point at which the project can be redirected as necessary.

Here, the process instruction is done incrementally and continuously. There is no team "leader" and the members all use the same processes. A pair of students selects a currently important story and works on it until it is completed or the iteration ends. The coach/instructor is available for both process and technical assistance.

---

Note that I'm describing some of the "personal process" practices of Extreme Programming, which I find useful in general.

My software engineering project as an undergraduate (many many years ago) involved teams of five. Later as a postgraduate I was responsible for the assessment for the same exercise. The marking scheme involved a 50% component of peer marking.

Not disclosed was that 30% of the remainder was related to the rms deviation of the marks awarded between team members. Consequently teams that agreed they had divided the work evenly got the bonus whereas teams who rewarded one individual did not.

There was a verification process of course, and moderation but the approach worked very well.