Experimenting with new ways of teaching

In yesterday's post, I talked a bit about trying to rely on lecture less and other classroom methodologies more. Today I tried out a new-to-me methodology: an in-class role-playing simulation. And surprisingly, it worked out extraordinarily well! In case you're interested, here's what I did. (I'll try to explain this without giving away too many details about the class itself.)

First, I came up with a problem that was large enough for the students to spend most or all of the class grappling with it, yet small enough to be manageable (and of course, related to the material they're currently learning). The problem was of the "suppose we were to design a system to do X" variety.

Second, I came up with three distinct roles for the students to play. The roles corresponded to three groups of people who would be interested in utilizing a system to do X, each of whom has its own vested interest in the system design. I typed up a description of each role, along with basic instructions for how the students should discuss the problem, and handed these out randomly to the class.

Once the students got their roles, they divided themselves into groups according to role and discussed the problem while "in character". This was the part I was most nervous about---would computer science students play along, or would they roll their eyes and half-heartedly participate? But the students totally got into their roles--and stayed in their roles throughout the class.

After discussing the problem in the role-groups for a while, I had one person from each group write the group's system requirements on the board. This was so the students could see the discrepancies in requirements between the groups, since each group has different goals in using this proposed system.

Then the fun began! Arguments erupted between the groups as to which requirements should take precedence. I tried to stay out of the way as much as possible, and in doing so found that the groups were eventually able to reach consensus on most of the points. After much back-and-forth discussion, we came up with a common list of requirements, along with a list of technical limitations that should factor into the system's design.

It just so happens that my school is in fact looking into systems that do X, and so I ended class by showing the class the requirements document from that real-life project. And we had a frank and interesting discussion about what the real-life requirements document implied about the real-life software selection process, and the fundamental differences between our requirements and their requirements (and thus between the processes).

I have to say that I was completely blown away by what my students came up with in such a short time. It was clear that, by doing this exercise, they had a much more accurate and complete understanding of the material than they would have had I spent the period lecturing about it instead. Moreover, they even tied in material from previous weeks, and did so seamlessly and naturally. I'm a believer now!

teaching-carnival