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). Part 6-10 reviewed the first several weeks of classes. Part 11 wandered off into philosophy.
Where We Are Going
Last entry (Part 12), the basic TBL lessons about group activities were discussed. The general framework of the 4-Ss covered a Substantial question, the Same for all groups, with a Specific choice, and Simultaneous reporting out. Implementing those features is as much art as mechanics, however.
This entry will fill out some details and add a bit of superstructure to the basics. A couple of questions are also raised.
In the “Facilitating Application Activities” article from Team-Based Learning in the Social Sciences and Humanities (2112), Jim Sibley sets group activities as “the keystone integration and knowledge-building events of any TBL module” that “must build on the foundational knowledge the students have gained during the Readiness Assurance Process (RAP).” He superimposes on the 4-Ss a “set-body-close teaching model.”
During the set phase, the instructor provides a frame of reference for the activity. Six elements (MMUCKO) are described.
Mood: Establish a clear, enthusiastic, supportive mood for the work.
Motivation: A narrative or story to focus attention.
Utility: Detail the usefulness of the knowledge to learned.
Content: The activities and tasks expected (the road ahead).
Knowledge: Activate the already reviewed materials by reminding the students what they already know and have prepared.
Objectives: The result desired at the end of the exercise.
This list covers a lot of ground. It will take some time for all this “set up” to unfold, even in the best of circumstances. Indeed, it could be a substantial commitment of class time if the students struggle with the context it provides.
Still, that time expenditure seems justified. A solid activities context appears crucial — it clearly enriches the activities that follow. Creating that background before every individual activity, however, curtails the number of activities that can be accomplished in a given class period. Longer, more involved individual activities creates longer intra-team discussions, running the risk of creating lag in the learning process, of giving rise to distractions, and of dropping the students out of their “flow” (I’ll pick up on this idea next entry).
My response is to lump the MMUCKO context creation in an “encounter background” presentation which sets up a series of related activities, shortening the intra-team discussion time, making the inter-team discussion more frequent, and building into something much more complicated over time. This approach runs the risk of simplifying the activities too much and making the intra-team discussion shallower. On the other hand, it provides more time for intra- and inter-team discussion because less time is spent setting up overall. Contrast a class that runs set up (15 min), activity (10 min), activity (10 min), activity (10 min), activity (10 min) with one that runs set up (15 min), activity (15 min), set up (15 min), activity (15). The former has 15 min set up and 40 activity; the latter mixes 30 min set up with 30 min activity.
Moreover, much as I like the concepts of the set up element, the example given does little for me as an aid in activity design. Sibley presents a MMUCKO with its elements noted in parenthesis:
“Based on your RAP scores, you’re all familiar with the basics of the Buddhist philosophy [knowledge]. Today we are going to examine Kamo-No Chomei’s “My Life in a Ten-Foot Square Hut” (which describes a 12th-century hermit’s view of catastrophic events in a much earlier period) and see [objective] if you can identify any clues [content/utility] to why the Japanese people have been so resilient in the face of the uncertainty and stress they have had to deal with in the recent earthquake and tsunami [mood/motivation].”
First, the objective/content “to see if you can identify any clues” is far too mushy. I presume that when the instructor gets to specific choice part of the 4-Ss, the objective gets much more concrete. If so, a follow-up series of activities, rather than one activity, justifies being “task loose” at the MMUCKO stage because the specifics will get filled in as class proceeds. If not, as we’ve seen from prior entries, looseness in the intra-team discussion task is a recipe for poor activities.
Next, I do not understand why “identify any clues” covers utility. Indeed, it strikes me that utility is wholly missing. What does the identification of causation (to the extent that is possible) as to the resilience of a people (to the extent that “a people” are a single entity that can be characterized as resilient) accomplish? My best guess is that it provides lessons in our own lives for standing strong in adversity. In that case, identifying the resilience as a “Japanese trait” undercuts the utility if you don’t happen to be Japanese.
Finally, to me, mood is the attitude you bring to the assignment of the task. That comes through in manner of presentation and description, not from any specifics of the task itself. Motivation, on the other hand, relates directly to the task and stems largely from the perceived utility of that task.
Again, I have no dispute with the concepts. My understanding of their impact, and the context of a series of activities, calls for a different approach. Another example could be elucidating, so I’ll use one from my class. Be warned, I based three or more classes’ worth of activities around it, so it is quite involved.
I’m a big fan of Kickstarter, Indiegogo, and other crowdfunding applications. I’m delighted to contribute to exciting and creative projects, even if they ultimately fall flat. One of my favorite endeavors is LiftPort’s Space Elevator. Clearly I’m not alone – with an initial goal of $8000, the campaign ultimately raised $110,000+. As a result, LiftPort is off and running. If you are intrigued, visit Liftport.com.
Indeed, I was so excited by the idea that I contacted the head honcho, Michael Laine, and asked what I could do to help. Once he discovered my background, he floated the idea of “Project Alexandria” — a database to help track all the information needed to answer the 1000s of questions that challenge the implementation of an elevator to space. He sent over the following, off the cuff, description of what he was looking for:
“ELEVATOR RESEARCH: THE ALEXANDRIA PROJECT, the sum of all knowledge. Organizing the 1000 questions that need answering.
Subjects: finance, law, policy, orbital mechanics, art, religion and theology, materials, failure analysis, robotics, communications, and computing.
Track who is working on the answer, what resources; current, past, and future experiments, prior studies, literature review on current documents. Collaborations among researchers. Discussion debate and branching. For example: “Best method for anchoring the lunar elevator to the lunar regolith” (lunar surface)
Needs basic categories, schemes and buckets, and tie sub buckets together. Maybe create a high level map: ID subject area, collaborations, researchers with biographies.”
As an initial matter, I love this description. It’s a brilliant example of a stakeholder’s take on the problem – varied, complex, disjointed, comprehensive, unorganized, open-ended. Exactly what a data analyst/designer/scientist (informatist?) is confronted with in his or her career.
Given this set up, here’s my review of the MMUCKO elements.
Mood: Enthusiasm for the enterprise to which the database project will contribute. An ambitious, science-based, important project is at issue — we are privileged to have the chance to work on such a problem. The organization and accessibility of information is crucial to the success of the elevator project.
Motivation: The story of the space elevator and what it could mean for humankind. The crucial part that the Project Alexandria database could play in that endeavor.
Utility: Working through the process of database design in the context of the complex Project Alexandria database provides a solid background in the process and could contribute to LiftPort’s endeavor.
Content: Working through goals statement, problem analysis, stakeholders, scope, use cases, requirements, data modeling, database implementation, and querying in the context of Project Alexandria.
Knowledge: The readings on database design/implementation process.
Objectives: The deliverable is a project statement/plan/model for a database that addresses Project Alexandria’s requirements.
And lo, an adventure is begun . . .