What Has Gone Before
In Parts 1-5, I discussed the Team-Based Learning methodology (TBL) course design for an undergraduate INF 202 Introduction to Data and Databases class, and drew parallels between TBL and roleplaying games (RPGs).
Where We Are Going
In this entry, we turn (finally) to the course itself. I run down events during the first week of classes.
As for registration, I have 24 students. That breaks down to four groups of six, enough members to keep things diverse and to account for attrition, but not so many that any one group member gets lost in the shuffle.
I started with a quick introduction of myself and my eclectic career path, then jumped right into team building. Recall that TBL course are centered around permanent groups. Given the large role they play in making the course work, I wanted to make sure I got them set up first and created the right diversity in terms of age/class year and skills. I decided to divide the students by year, then by Computer Science/Information Science major/minor.
The class is made up of roughly equal parts seniors, juniors, and sophomores, weighted slightly toward seniors. I picked class year as the first cut criteria because I wanted to divide the seniors as equally as possible to minimize the impact of senior-itis on the groups.
With respect to skill sets, I wanted to spread around the non-CS/IS majors. I think of them as most representative of end-users of databases (as opposed to designers) and I wanted their view represented in each group. (I actually made that point in the introduction, playing up their value to the group.)
So, I lined up the seniors by CS/IS major, CS/IS minor, other; juniors the opposite way (other majors/minors, CS/IS minor, CS/IS major), and sophomores like seniors. This “snaking” order seems to have created a good mix of majors/minors. Bigger problem was slotting in the new or first attending students on the second day. That took a bit of juggling. All in all, the complicated sorting process didn’t seem to faze the students and it seems to have accomplished my goals.
Next up: my first stab at activities. I’ll talk much more about activities as this blog continues—they are the major learning tool in TBL, but for now I’ll just say that I wasn’t entirely sure about what I was doing. I wanted something that could be done naively—the students had done no reading and couldn’t be expected to know much (if anything) about databases. Easy solution: the first group activity was to settle on a name for the team. I had each group pick an adjective for itself. The groups came up with Amazing, Tasty, Diverse, and—after a bit of a lag—Slow.
For the next activity, I asked them to list one thing they liked about a prior class and one thing they disliked. Not surprising, activities were thumbs-up and lectures were not so great. Among the dislikes were endless lecture, little discussion/interaction, and final exams. (I am assigning a final project, not an exam.) For all three of those I was able to say, “we won’t have any of that in this class.” No one said they disliked group work, which was surprising (given how often group work assignments are poorly designed—for example, writing a paper with a group is asking for unequal member effort).
Next, I assigned a content activity. I asked each group to come up with 5 entities that collect data and 5 data points that each entity collects. This was a hard task, but I did not appreciate that. I’m thinking about data all the time, so to me it was relatively easy to identify, say, the IRS as a group that collects income, family, SSN, deduction, and residence information. Worse, I was essentially asking for 25 answers in one activity. That far too much work for a single activity. Finally, such a “creation” exercise was bound to result in vastly different answers from each group, making it difficult to generate a give and take among the groups.
Next, I had them pick a noun to add to their group name. This gave them a chance to bond a bit more as they worked out their names. They were tentative at first but got into the spirit of things as time went on. The fact that they had to combine their prior picked adjective with a subsequently picked noun during the fourth activity sparked the most discussion. In the end, the class wound up with the Amazing Avengers, the Tasty Treats, the Diverse Individuals, and the Slow Thoughts.
Finished up the first class with several database mash-up activities (a novices’ exploration of open data and big data).
All in all, and again not surprisingly, the students were pretty tentative. Apparently, no one had experienced a TBL class before. Group discussions were not very loud and were not very long. Still, there was some discussion and their answers did leave me the impression that they groked the exercise.
As I mentioned in Part 3, I varied a bit from TBL by using mechanical roles. I assigned a caller (person who writes group decision on white board and takes first stab at explaining them) and scribes (person who takes attendance and notes for the group and turns in summary of decisions/answers). My thinking is that these folks will act as timekeepers/facilitators because they have a vested interest in having the group reach a decision (so they can write it down). My plan is to have the roles rotate around the group as the semester progresses so everyone takes on each role at one time or another. In fact, in keeping with the ideals of “empowering students” and “students organize their responsibilities”, I created a grid that the groups fill out as they go. Given my requirement that “each of you must take on each role at least three and no one should take on any role more than three times”, they can decide who takes each role when. That leaves the group (not me) to juggle absences.
During the second class, I conducted my first RAT—on the syllabus. Given how different TBL is from the students’ prior university existence, and given that I’m a game designer, I felt it was a good idea that the students spend some time learning the “rules.”
As far as results, the individual RAT (iRAT) scores varied from 80 down to 40, grouped around 70. Team RAT (tRAT) scores were 83, 80, 75, 75. In sum, the tRATs were better than the majority of the iRATs. Worked perfectly—team work and worth were validated.
I then announced the appeals process and gave them 10 minutes to work on it. During appeals, the teams can challenge any RAT question they felt was misleading or poorly constructed, or can offer a rationale for counting another RAT answer as “just as good as” the one I set as the correct answer. Three teams turned in appeals, two of them on the same question. One appeal was spot-on. They picked one of the “wrong” answers and gave a sentence or two why it was as good as my “correct” answer. The other two just argued against my “right” answer. They didn’t present a better or “as-good” answer, and defend it. I returned those two appeals and said I would accept a reformulation by the end of the next class. This was the first group activity that generated real noise/discussion (despite one group that decided not to appeal anything). Lesson learned: give the students a real (read: grade) stake in something and they can get animated stat!
We finished with a grade weight assignment activity. I took the advice I got not to open up the entire process. I just allowed the groups to decide how to weight the iRATs vs. the tRATS (40-60, 50-50, 60-40). Total fizz. After almost no discussion, every group went with 40-60 (weighting tRATs heavier). Given the prior results (tRAT results so much better than iRAT results), this outcome really wasn’t much of a surprise. Even so, I’m glad I did it because I think it built a bit of team cohesion. For purposes of generating discussion, however, it was a non-started. Might try to open up more parts of the course for grade weight discussion next time.
More to come,
M Alexander Jurkat