Teaching collaboration – overview

There are quite a few aspects to this that I think are important. As I considered the comments posted here and other verbal comments that I have received, it has become clearer that I think the factors fall into at least two main groups: classroom constraints, and task aspects. In the area of classroom constraints are several issues that the teacher / facilitator needs to work around. In the area of task aspects, I’m jumping off from Ellen Gottesdiener’s book, Requirements by Collaboration as well as other sources. (I haven’t had Ellen’s class, so if I’m off base, please let me know!)

Under classroom and teaching constraints, we have several challenges:
- varied skill levels of the students / participants
- varied goals of the students / participants / (and, at times, sponsors, alas)
- varied learning style preferences (I’m appreciating this aspect more and more with Andy’s research)
- varied past experiences with trust, with the other students, people at large, and in this kind of situation
- and the need to justify the importance of collaboration skills and experiences to the students to gain their cooperation

In the area of the task aspects, Ellen mentions the need for these things for collaboration to take place:
- a shared purpose exists (see the problem with goals above)
- mutual trust
- agreed upon approaches to work

She also mentions the need to acknowledge the existence of different, equally valid viewpoints. While she is focusing on developing requirements, it would seem that these things would be equally true for any collaborative efforts.

Harrison McKnight , at Michigan State University, has done considerable research on the issue of trust, in general and as it relates to IT. I’ve been going back over some of his work as I think about collaboration between testers and the rest of the development team. I’m going to work through the topics I listed above in the next series of posts and will get in to his work on trust as I do.

In thinking about this, I also dug up an article from 1999 by Timothy Lethbridge on “Priorities for the education and training of software engineers”. I was curious to see if there was anything resembling this topic in his list of 75 topics that they surveyed junior and senior practictioners about. The closest I could see were negotiation, psychology, and management. They asked, among other things, how much people had learned in their formal education about each topic. Negotiation was # 75 out of 75. All of the “soft skills” were in the bottom third. What did they forget the most from their education? Differential equations, differential and integral calculus, and linear algebra and matrices.Hmmmm.

Preparing CompSci students for group work?

“Are schools not properly preparing computer science students for group work in professional situations?” asks Tim Van Tongeren in response to a quote about students actively avoiding group work in completing their (group) assignments. My first thought is “How do you prepare someone for group work as a collaborative experience?” It also made me remember a comment from Brian Marick’s blog back in June: “Agile projects have some tricky differences from conventional projects – …(including) a greater dependence on trust between members of different interest groups “ At the time of Brian’s post, I considered responding by saying that I would hesitate to say that there is a significant difference in the dependence on trust between members in agile and non-agile projects. I think that all projects require strong trust to be collaborative, not just agile projects. (I admit to very limited exposure to agile projects, but I have seen the impact of trust and dis-trust on non-agile projects. In my experience, it is absolutely critical to effective collaboration of any sort.)

That brings me to Tim’s question, and a second question in return: How important is trust, or lack of trust, in the students’ choices about whether to work together for group projects? If trust is required for collaboration, as I have observed and as some research is beginning to bear out (I can provide the academic references if anyone is interested), is it reasonable to expect that a teacher can somehow generate trust between group members to enable this collaborative experience?

I do think that it would help students to have had a genuinely collaborative experience. Without it, they may be less likely to put in the work to be part of a collaborative team. I’m not sure that any computer science, or even MIS / business school, class is going to address that well without specifically addressing trust issues. (Business schools are notorious for their group projects, but I haven’t seen much greater success there either.)

I’ve been on a project that did not begin, but became incredibly collaborative. Without exception, the team members were changed by the experience. It never would have happened by just having someone tell us to be collaborative and/or to trust each other, though. The trust was earned, over time and through positive experiences, at both the group and the individual pair levels. It was also fostered and consistently demonstrated by a talented project manager and the project leads. Given the constraints that schools are functioning under these days, can we expect them to prepare students for that aspect of professional work? If you think of what has made your groups successful, could that be replicated through class assignments?

Or is there a different question altogether – if most projects are not as collaborative as we would like, is the classroom perhaps more correctly mirroring reality than our desires?