Last year I conducted a series of interviews with students and our practical supervisors and tutors on the nature of collaboration – what kinds of activities they liked to do collaboratively, what they disliked, their feelings towards collaborative activities in courses, and how they approached those kinds of activities? There were three main things that came out of the interviews that I found interesting: (1) how grade focussed the students were in terms of collaborative activities, (2) how they explicitly avoided collaboration in their approach to structuring their activities and (3) their preference for collaboration was it was only indirectly tied to a deliverable. I’m still in the middle of analysing these discussions, and hopefully we will publish a paper on this later this year, but I think we can learn a lot from these initial conversations as to how to approach collaboration in our classes.
The initial feelings by almost all of the interviewees were that collaboration was “a good thing”. They understood that it was a useful skill for their future, and why it was included in their classes. But – they tried to avoid it whenever they could. They had a major issue when a group grade was allocated to the work, even in cases of weaker students, they felt that they would be doing more work than other students, and that it was a problem that other students would be benefiting from their work. They would often say things like “it would be fine if collaborative activities were included informally, in practicals or tutorials”. Interestingly, they would frequently comment later in the interview about how they felt they learned more when working with others.
When asked how they usually undertook a collaborative activity, I was surprised by how many of the interviewees commented that they broke up the activity into parts, allocated a part to each participant and then got together just prior to the end of the activity, when it was due for presentation or submission, to bring everything together. The times that they work collaboratively are at the start of the activity, when breaking the activity up into distinct parts, and then again at the end, in the integration stage.
It is clear, from these discussions at least, that when we set collaborative activities, we need to do a lot more to actually guarantee that collaboration is occurring. Our students try to break the problem up so that they can continue to work individually. This is, of course, a skill that Software Engineers need to have – we often allocate components of a software system to be completed by individuals, but is this really what we want our students to be doing? We need to separate out collaborative learning from learning the professional practices of a Software Engineer. It can be very easy for us to put these together and think we are covering both skills, as collaboration is one part of this professional practice, but I don’t think it is as simple as that. We need to explicitly address each of these, so that students can build from one to the other.
But why do we want our students to learn to work collaboratively? The short answer is because it is a skill that will help them learn more in the future. The purpose of working collaboratively is to learn with the group – the premise (see Vygotsky) is that (to paraphrase) “learning awakens a variety of internal development processes that operate only when the child is interacting with peers/others”. In this view, learning is a social process – the basis of collaborative learning approaches is that students will be able to learn new material, building connections between concepts and internalising new knowledge that will then leave them able to operate independently; and that students learn more and learn more quickly and deeply by doing so. If we want our students to really make use of the benefits of collaborative learning than we need to ensure that they have the skills, both social and academic, to communicate and collaborate.
My feeling is that, for students, we need to impose more structure and expectation on how collaboration occurs and to teach our students, or perhaps provide opportunities for them to learn, how to collaborate. When working as a professional – blending individual and team work – they will then know when (and how) to seek collaboration that will be fruitful. This is not a mind blowing statement – there are many guides to types of collaborative exercises that we can use. However, I do think that we can do more to promote the use of more structured approaches to collaboration, particularly in the scope of larger project work, and to understand and discuss why these approaches work and are useful.
The final point, and unsurprising given the preceding points, is that students prefer collaborative activities that are not directly deliverables. They indicated that they were very happy with working collaboratively on designs, or testing – anything that was more explicitly about problem solving. They very much preferred to work individually on writing code, documentation or presentations. Linking back to the second point, they would approach any collaborative activity in the latter category in parts – slides of a presentation, sections of a document, components in a software system, with a subsequent integration step. And linking back to the first point – my feeling is that this gave them a good sense of ownership of their part – even if being graded as a group, they felt that their individual expertise had been demonstrated. I need to explore that further with some follow up interviews and perhaps some surveys, I think.
So how does PBL fit in here? I think that is enough for today, but I’ll discuss that in my next post.
(Lev Vygostky (1978), Interaction between Learning and Development. From Mind and Society, pp 79-91. Cambridge, MA: Harvard University Press).