battis.net

Nate Kogan, writing about his plans for “classroom 2.0″ collaborative writing assignments in his history classes in the coming year, notes student resistance to working collaboratively:

While many students seem to dislike group work, I think the resistance stems more from the fear of being saddled with all the work by one’s potentially indolent group-mates rather than from inherent resistance to collaborative work.

[Full disclosure: Nate is my brother-in-law, and I have been following his thoughts about teaching with technology with some interest all summer.]

While studying for my M.Ed., I found myself revisiting the role of student full-time after a decade-long hiatus: it brought me back to the classroom with fresh eyes. The process raised two big pedagogical questions for me:

1. How do I teach my students to ask questions? Not even good questions, just questions. I realized that, as a long-time A student, I’d never spent much time confused, and therefore hadn’t had to spend much time figuring out how to get unconfused. Over the course of my studies, I realized that this might be the most important thing that I, as a high school teacher, might be teaching any of my students. And, never having been taught (or, at least, never having noticed being taught — merely encouraged to just do it) how to learn reflectively and ask questions that clarify and resolve my areas of confusion… I was (am) a little at sea about how one teaches this intentionally.
2. How do I teach my students how to work collaboratively? This is, after all, what the real world is about. It’s vanishingly unlikely that my students will find a role for themselves in which they don’t have to work with other people toward a shared goal (okay, one or two of them may turn out to be costumed superheroes or reclusive, genius novelists… but the vast bulk are going to have to play well with others).

I think that these two questions are related: working collaboratively with peers creates a more free-flowing and less performance-anxiety-inducing environment than working independently and presenting to the teacher (and one’s classmates). Or, at least, it can. That environment could, if the stars align and sufficient support and guidance is provided, even result in an setting in which students are free to debate, critique and improve each other’s work. That is, they could learn how to reflect on what they’ve learned and ask questions of each other about that work and the progress that they have made.

In graduate school, I had a wealth of group project experiences. The least successful was my year-long “school developer” project that was, effectively, my master’s thesis with a group of four other students working with a local elementary school to develop a strategic plan for expansion from K-5 to K-8. Lord, this experience was miserable, partly because my Meyers Briggs profile was the complete inverse of my teammates, and partly because we had no idea what we were doing as a team and were thrown into trying to do things before we actually were a team. (It calls to my mind my panicky, parental feelings of inadequacy when my classes have to interact with outsiders early in their time together — I don’t trust them enough to believe that they’ll be presentable, and they don’t trust me enough to believe that I haven’t set them up for a fall or for boredom.) Long story short, the team suffered from terrible group dynamics, mission creep, lousy communication with our “client” school, confusing feedback from our peer teams and professor, and unclear end goals for both the class project and the school’s mission.

The most successful team of which I was a member was actually formed to write a single collaborative paper over the course of the semester. The professor, Janice Jackson — a former elementary school teacher and district administrator and all-around mensch — spent the first half of the semester devoting significant portions of class to not only teaching about group dynamics in the abstract, but giving us time as teams to work through those very dynamics as we learned about them. By the time we had any kind of work for which we were accountable, we were, quite honestly, a little tired of meeting and exasperated at Prof. Jackson. It all felt excessive. However, when we sat down to do our research and write it up, it turned out that all of our (very diverse) Meyers Briggs personalities meshed, that we each had clear roles within the group that we had explicitly negotiated, that we had clear expectations both of each other that we had explicitly stated and of what our end result should be (that we had proposed and had approved by Prof. Jackson, explicitly), and that we felt safe working through early drafts of our paper sections together and receiving what was sometimes drastic criticism and demands for reworking.

The process matters. It really, really matters. And that class with Prof. Jackson was the first time that I had ever worked in a group in an academic setting that had consciously set aside (or had set aside for it) time to figure out how to be a group. That that experience was bolstered by conceptual background in group dynamics surely didn’t hurt. Prof. Jackson gave us both the time and background to develop clear understandings of both the norms of our group and our own roles within the group. And this idea of understanding one’s role in the group, and trusting one’s collaborators to fulfill their own roles and responsibilities, is key to successful collaboration. Without that trust, one ends up either abdicating all responsibility (“yeesh, what a bunch of clowns — there’s no way we’re going to do well, why should I try?”) or striving to fill in all the perceived gaps (“yeesh, what a bunch of clowns — if I want it done right, I’ve got to do it myself.”).

So, how to develop this experience of a trusting, collaborative project with high school students? They’re certainly at a different developmental place than I was at 30 (well, I hope they are — mostly for my sake). I don’t think that loading them down with all the conceptual background and vocabulary that we received from Prof. Jackson will make a sale to them. But I do think that striving to develop that environment of trust and delegation among teammates, with clear understanding of roles is worthwhile.

I’ve tried to do this in a number of settings. When I was working at as an outdoor, experiential educator, I found that large group projects could be done well by delegating specific roles within the project to specific students, thus providing clear accountability for specific portions of the project. My preferred iteration is to work with the students to develop a top-down design (what Wiggins’ confusingly refers to as a “backwards design”) that parcels out the work into self-designed and allocated responsibilities. One iteration of this was to present a large question to the group (“How does human management impact the ecosystem?”) and then help each student develop an area of expertise within the larger question (water, birds, tourism, sound, etc.). The wrinkle is that no student can accurately predict a topic in which they will maintain an abiding interest throughout the project, and therefore slippage and shifting will occur and needs to be negotiated gracefully.

Another approach, which I used last year with my Application Design class as we were working to build a CNC lathe, was to break the project apart into modules with the class, and then solicit volunteers for small teams to tackle each module. We prioritized the modules, and each student was responsible for shifting from module to module as they were interested or the module needed development to support dependent modules of other teams. Students were encouraged to engage with other teams, and sometimes shifted from team to team based on changing interests, but there was always a core student or pair of students who was, at the end of the day, managing each module and responsible at least for rallying other students to that module’s cause.

In both cases, I found that developing clear (and concise — unlike this entry) roles for the students in collaboration with the students gave them significantly more buy-in. Students who engaged with the project were able to throw themselves into it without fear of having to “carry” their peers (each student’s contributions were documented along the way — automatically by Google Code, in the case of the CNC lathe project), and, in fact, over-achieving students tended to provide a catalyst for under-achievers: they asked thoughtful and critical questions, provided assistance and generally raised the intellectual atmosphere a notch or two. Simultaneously, the multiplicity of roles and modules provides enough overlap that if one or two students totally peace out, the rest of the team can gnash their teeth briefly and move on without being hindered or damaged. Where successful, I found that I had students who were pushing me to do more research to support their work and that I was relying on their work and questions to lead the class.

In both cases, I also took some significant time out both early on and throughout the project to step back, examine and work through group dynamics. Not necessarily conceptually, but pragmatically working to resolve issues and grudges (and, not insignificantly, to celebrate and highlight successes). While I strongly encouraged my students to hold each other accountable and to work issues with their teammates out with their teammates, I was also a consultant to individual exasperated students on how to do this, and a general-purpose umpire for the whole team, calling time-out when it looked like a brawl (or tears) was brewing. In my umpire role, I was also able to highlight particularly good or interesting work by individual students or teams for the entire class, providing a clear model of the desired outcomes and behaviors.