7
DEBORAH A. TRYTTEN School of Computer Science University of Oklahoma ABSTRACT Although the industrial partners of academe are unanimous in their desire to hire engineering graduates who are experienced in working productively in small groups, implementing small group work in a computer science class can be difficult. The obvious as- signment, a group programming project, proved to be a poor choice when implemented in my computer graphics class. An ex- amination of the literature in this area shows that a group pro- gramming project has many features in common with a group term paper, the assignment that has been uniquely identified as the worst choice for small group work. Fortunately, there are better choices for cooperative learning in computer science. Assignments with “the three S’s”: Same problem, Specific choice, and Simulta- neous reporting of group choices, work well. This was implement- ed in my class by having students work multiple choice quizzes de- signed to require high level learning skills. Quizzes were first worked by individuals, then by small groups. The small group an- swers are then compared and discussed in class. This generates the type of interaction between the professor and students which cre- ates positive cooperative learning experiences. Promising results have been seen with this method, from both the student and the professor’s perspective. I. INTRODUCTION The industrial demand for software engineers who are well pre- pared to work in groups led me to integrate group programming projects in a computer graphics course. Even though the course was carefully designed and planned, the experiment was not initially successful. This was not unexpected, given the observations that in the early phases of team learning, students initially go through the classic grief process 1 to mourn being forced to bear more responsi- bility for their own learning. The degree to which it occurred, how- ever, was unexpected and alarming. After consultation with experts in cooperative learning, it was discovered that the group programming project assignment was, in fact, a poor choice. This result is surprising since group program- ming projects are such an obvious choice, given the industrial con- text of computer science. The small group assignments were re- structured to create a cooperative learning environment, which has been much more successful. This structure of these assignments is applicable to many computer science classes, as well as classes in other engineering disciplines. II. SMALL GROUP WORK Since computer scientists in industry typically work in teams, in- dustrial representatives have been encouraging faculty in computer science to integrate more small group projects into classes. 2,3 This section will describe the literature on managing small group learn- ing in the classroom. A. Assigning Small Groups There are many elements that must be considered in the selection of small groups. The ideal group size is between four and seven mem- bers, inclusive. 4 Groups of five or more students may be desirable in classes where a significant number of students typically withdraw during the term, since they will not leave behind a group disadvan- taged by being of insufficient size. Groups of size six or seven have higher transaction costs (the amount of time and energy which must be spent arranging and attending group meetings), if a significant portion of the work is to be done outside of the allotted class time. Group membership should not be altered during the term to allow group members a chance to learn to work together better over time. Heterogeneous small groups have been consistently found to be more effective than homogeneous small groups. A study of five methods for assigning small groups found that groups function best when they are heterogeneous with respect to GPA and homoge- neous with respect to interest (as is common in engineering classes). Groups which were self-selected by students were found to have the poorest attitudes about their instructor, the projects, their class- mates, and the course. 5 Heterogeneous groups were also found to be superior when GPA, outside activities, practical experience, and learning style differences were considered. 6 There is one dimension along which heterogeneity may not be desirable. When members of under-represented groups are in the class, it has been shown that they should be clustered together in small groups. 7,8 B. Peer Evaluation To avoid social loafing (the tendency of people to work less when grouped), it is essential that individual contributions be evaluated January 2001 Journal of Engineering Education 85 Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science* *Based on “Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science” by Deborah A. Trytten, which appeared in the Proceedings of the 1999 Frontiers in Education Conference, San Juan, Puerto Rico, 10–14 November 1999, IEEE Catalog No. 99CH37011, pp. 13a4-22 through 13a4-27, © 1999 IEEE.

Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

Embed Size (px)

Citation preview

Page 1: Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

DEBORAH A. TRYTTENSchool of Computer ScienceUniversity of Oklahoma

ABSTRACT

Although the industrial partners of academe are unanimous intheir desire to hire engineering graduates who are experienced inworking productively in small groups, implementing small groupwork in a computer science class can be difficult. The obvious as-signment, a group programming project, proved to be a poorchoice when implemented in my computer graphics class. An ex-amination of the literature in this area shows that a group pro-gramming project has many features in common with a group termpaper, the assignment that has been uniquely identified as theworst choice for small group work. Fortunately, there are betterchoices for cooperative learning in computer science. Assignmentswith “the three S’s”: Same problem, Specific choice, and Simulta-neous reporting of group choices, work well. This was implement-ed in my class by having students work multiple choice quizzes de-signed to require high level learning skills. Quizzes were firstworked by individuals, then by small groups. The small group an-swers are then compared and discussed in class. This generates thetype of interaction between the professor and students which cre-ates positive cooperative learning experiences. Promising resultshave been seen with this method, from both the student and theprofessor’s perspective.

I. INTRODUCTION

The industrial demand for software engineers who are well pre-pared to work in groups led me to integrate group programmingprojects in a computer graphics course. Even though the course wascarefully designed and planned, the experiment was not initiallysuccessful. This was not unexpected, given the observations that inthe early phases of team learning, students initially go through theclassic grief process1 to mourn being forced to bear more responsi-bility for their own learning. The degree to which it occurred, how-ever, was unexpected and alarming.

After consultation with experts in cooperative learning, it wasdiscovered that the group programming project assignment was, infact, a poor choice. This result is surprising since group program-ming projects are such an obvious choice, given the industrial con-text of computer science. The small group assignments were re-structured to create a cooperative learning environment, which hasbeen much more successful. This structure of these assignments isapplicable to many computer science classes, as well as classes inother engineering disciplines.

II. SMALL GROUP WORK

Since computer scientists in industry typically work in teams, in-dustrial representatives have been encouraging faculty in computerscience to integrate more small group projects into classes.2,3 Thissection will describe the literature on managing small group learn-ing in the classroom.

A. Assigning Small GroupsThere are many elements that must be considered in the selection

of small groups. The ideal group size is between four and seven mem-bers, inclusive.4 Groups of five or more students may be desirable inclasses where a significant number of students typically withdrawduring the term, since they will not leave behind a group disadvan-taged by being of insufficient size. Groups of size six or seven havehigher transaction costs (the amount of time and energy which mustbe spent arranging and attending group meetings), if a significantportion of the work is to be done outside of the allotted class time.Group membership should not be altered during the term to allowgroup members a chance to learn to work together better over time.

Heterogeneous small groups have been consistently found to bemore effective than homogeneous small groups. A study of fivemethods for assigning small groups found that groups function bestwhen they are heterogeneous with respect to GPA and homoge-neous with respect to interest (as is common in engineering classes).Groups which were self-selected by students were found to havethe poorest attitudes about their instructor, the projects, their class-mates, and the course.5 Heterogeneous groups were also found tobe superior when GPA, outside activities, practical experience, andlearning style differences were considered.6 There is one dimensionalong which heterogeneity may not be desirable. When membersof under-represented groups are in the class, it has been shown thatthey should be clustered together in small groups.7,8

B. Peer EvaluationTo avoid social loafing (the tendency of people to work less when

grouped), it is essential that individual contributions be evaluated

January 2001 Journal of Engineering Education 85

Progressing from Small Group Workto Cooperative Learning: A CaseStudy from Computer Science*

*Based on “Progressing from Small Group Work to Cooperative Learning: ACase Study from Computer Science” by Deborah A. Trytten, which appeared in theProceedings of the 1999 Frontiers in Education Conference, San Juan, Puerto Rico,10–14 November 1999, IEEE Catalog No. 99CH37011, pp. 13a4-22 through13a4-27, © 1999 IEEE.

Page 2: Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

and graded. For peer evaluation to be meaningful, it must be a sig-nificant factor in the final grade.

One method for performing peer evaluation is to have studentsdistribute 100 points among the other members of the group. Thisforces team members who wish to unfairly reward team memberswith lesser contributions to do it at the expense of the most signifi-cant team contributors. The peer evaluation scores are then used asa multiplier on the assignment score, as shown in Table 1, or as apercentage of the final grade. Table 1 shows the peer evaluationscores for a four-member group. If the group grade for the assign-ment was a 90, the individual grades would be as given in the lastrow of the table below. Member D receives the full 100 points, eventhough the group received only 90, because of strong peer evalua-tions, while member C receives only 81 points. This method causespeer evaluation to be heavily weighted since a group member could,theoretically, receive a grade of zero for the assignment if the peerevaluations were all zero.

C. Team BuildingThere is a period of adjustment that occurs when groups of peo-

ple begin to work together. Each individual arrives with a collectionof strengths and weaknesses, which are largely unknown to theother members of the group. It takes a substantial amount of timeto learn to take advantage of the strengths of team members andovercome their weaknesses. Team building exercises are used to ac-celerate this process. A good team building exercise has the follow-ing features:

● allows student to see that he/she is able to perform reason-ably well in a group

● exposes students to the resources available to their group● demonstrates that the individuals in the group can function

as a team● builds interdependence and mutual support in the newly

formed groups● demonstrates instructor commitment to successful group

work● allows early instructor intervention in dysfunctional groups.A simple team building exercise is to give students a selection of

raw materials and have them design and build an item with desiredproperties. When each group has completed construction, theproducts are compared between groups.

One version of this exercise, used by Leslie Fife at OklahomaCity University, requires students to build a tower of 2 3 2 Sty-rofoam blocks which has the highest ratio of total blocks toblocks touching the table or floor. Students are given 20 blocks

to use during a 15 minute planning session. Groups are givenan apple box full of the same blocks and 15 additional minutesto build their towers before the towers are compared betweengroups.

Another version of this exercise, used at Cargill during the ITJunior Challenge, is to give students 1 egg, 2 balloons, 12 inches ofmasking tape, 1 piece of white paper, and 24 inches of string. Thestudents use these materials to build a container that will protect theegg when it is dropped from the maximum height. Broken eggsand balloons are not replaced. It takes about 30 minutes for stu-dents to design and construct these containers. Dropping the con-tainers at the end of class can be messy. This is the team buildingexercise that I use regularly.

III. THE ORIGINAL DESIGN

In spring of 1997 I began working with small groups in my CS4053/5053 Computer Graphics course. This course is offered oncea year to both undergraduate and graduate students. The prerequi-sites for the course are data structures and linear algebra. The classsize was in excess of seventy students. Groups consisted of four tofive students. Groups were created to maximize diversity, exceptthat the four women in the class were all placed in a single group.There were no other members of under-represented groups in theclass.

The dimensions that were used to determine diversity were:● undergraduate or graduate student ● CS major or not● GPA ● full time or part time student ● native or non-native speaker of English● whether the student had significant work experience in CS

or not● gender● race● whether the student had passed a software engineering class

or not.Students were also asked to identify any relatives or close personal

friends in the class to prevent them from being grouped together. Small groups were created in such a way that every group except

one had at least four hours during the week when all members re-ported that time available. Assigning the groups took a full after-noon, due to the complexity of scheduling. This is a valuable lessonon how high transaction costs can be for students when doinggroup work outside of class time. Groups stayed together for theduration of the term.

After the ungraded in-class team building exercise, small groupswere asked to perform large programming projects collaboratively.Each group worked on essentially the same project. The only dis-tinction between group projects was that groups could choose tocompete for 10 of the 100 points for original additions to the pro-jects, called enhancements. Enhancements were graded on thebasis of originality. A group which animated a robot for a projectmight enhance it by adding additional objects to the scene, or byimplementing a complex or interesting move such as a back flip.Groups which chose not to do enhancements, would receive atmost 90/100 points. These programming projects made up half ofthe grade in the class.

86 Journal of Engineering Education January 2001

Table 1. A sample peer evaluation calculation.

Page 3: Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

A. Peer EvaluationThe peer evaluations for the first few projects were conducted by

having students email their peer evaluation numbers to the instruc-tor. It soon became apparent that the raw numbers did not providesufficient feedback to students, and a more comprehensive peerevaluation form that required students to defend their numericalratings was created and used. The questions below were taken fromnumerous sources, including peer evaluations done by several facul-ty members at the University of Oklahoma. This improved formcontains the following questions about the interaction of thegroups.

● Rank the members of your group, including yourself, accord-ing to how much (both quality and quantity) they con-tributed to the group effort.

● Did any person dominate the group efforts? If so, who?● Do you feel anyone in the group relied to heavily on others to

provide the answers or do the work? If so, who?Students were then required to answer the following questions

for each individual in the group.● When the group met, what percentage of the time was this

person present?● How often did this person lead the way for the group?● If this person had not been a member of your group, do you

feel the group performance would have suffered, and if so, inwhat ways and to what extent?

● What were this person’s strengths in contributing to thegroup effort?

● What were this person’s weaknesses in contributing to thegroup effort?

● How often were this person’s ideas or suggestions acceptedby the group?

● What percentage of the group’s performance (quality andquantity) do you feel this person contributed? Rate onlymembers of the group other than yourself. If you had a fourperson group and everyone contributed almost equally, twopeople would get 33 points, and one person would get 34.

● Please rate this person’s overall performance by circling theresponse which best fits. Please explain or justify your ratingand put any other comments on the back of this page. (Rat-ings: Excellent, Very Good, Satisfactory, Fair, Poor.)

When these forms were submitted, I read them for each indi-vidual and created a composite evaluation informing students of thescores and giving them feedback from other group membersanonymously (e.g. The members in your group say that you fre-quently lead the way, but also tend to dominate the discussion).The typical student probably spent less than fifteen minutes fillingout the forms on paper. Forms were submitted following each pro-ject. The improved feedback from this form allowed me defend thepeer evaluation scores better and to suggest that some students cor-rect peer evaluation scores that were not consistent with the writtenfeedback. All of the corrections were suggested when the writtenevaluations of an individual clearly indicated that a person con-tributed little, but was given a high peer evaluation score. I did notalter the peer evaluation scores without the consent of the individ-ual who had performed the evaluation.

B. ResultsThe results were not promising. Students complained continu-

ously and bitterly about having to work together. Many groups re-

ported difficulties with social loafing and excessive transactioncosts. Students continually begged to be released from small groupwork in favor of individual work.

There were several small groups with interpersonal problemssignificant enough to require intervention by the instructor. Onegroup became so dysfunctional that these interventions were heldweekly. Two of the students in this group recently reported to methat they never again spoke to any member of their small group inthe class, not even in passing.

The projects, which were finished, were clearly being accom-plished by the strongest individuals in the groups working in isola-tion, depriving other group members of the necessary understand-ing of class material. Several groups failed to submit a workingversion of several projects. The peer evaluations generated consid-erable controversy, and students asked the instructor to edit themfor a variety of invalid reasons. Some days it seemed that every oneof the unwelcome group members described by Lerner (from NolaNo-Can-Meet to Do-It-All Dottie) were in each and every smallgroup in my class.9

During the course of the semester, a number of attempts weremade to fix the problems after consultation with an expert in smallgroup learning. Group project demonstrations were scheduled simul-taneously and groups were required to evaluate each other’s base pro-ject and enhancements, in the hope of building healthy competitionbetween groups and establishing group identity. The same multiplechoice quiz was given both to individuals and groups (in sequence)before the programming projects were begun to force students to de-velop and demonstrate basic knowledge of the topic before beginningprogramming. These quizzes became 20% of the project grade.These measures did pacify some students, perhaps because they feltthat the instructor was actively working to address problems, but thevast majority of small group problems were unaffected.

The one bright spot in the semester was that the group com-posed of only women consistently outperformed all other groups,reinforcing the sometimes controversial idea of clustering membersof under-represented groups. A recent discussion with one of themembers of this group confirmed that being in a group wherewomen were in the majority was one of the most significant andunique experiences in her education.

After the semester was over, several students reported that theirgroup used clandestine means to conceal the lack of group interac-tion. These groups “diversified” code written by a single individualso that it would appear to be a group effort by having other groupmembers reformat the code to appear to be in a different program-ming style. Several students reported that this tactic is regularlyused by small groups when performing programming projects inother classes. Another student reported that his group had electedto have each group member create one project, even though theprojects were thought to be too large for this to be physically possi-ble. The student evaluations of the instructor were significantlylower than previous years, although the in-class content of thecourse had not changed. The fall after the class, several studentsfrom this class took time out of their busy schedule to stop by theEngineering Fair and pay $1 to hit me with a whipped cream pie(in previous years, and every year since, only playful and friendlystudents have stopped by). One student paid for three pies. Inshort, the group programming projects were a disaster from everyperspective. The benefits of small group learning10 were not beingseen in my class.

January 2001 Journal of Engineering Education 87

Page 4: Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

IV. COOPERATIVE LEARNING

When I had assigned group programming projects, I had hopedto gain the well publicized benefits of cooperative learning. Al-though cooperative learning requires that students work in smallgroups, requiring students to work together in a small group doesnot necessarily generate a cooperative learning experience.

Cooperative learning occurs when a group of people have11:● joint goals● mutual rewards● shared resources● complementary roles.Small group projects do not necessarily have these attributes. As

an example, two students may have very different goals for a groupproject. One student may have a heavy class load and want to spendas little time as possible on the projects, even if his grade suffers.Another student may view the project as a way to defend againstweak test grades and not be satisfied with any grade less than 100,even if that means spending an unreasonably large amount of timeon projects. A small group, which contains these two individuals,may have difficulty with social loafing since the first student may behappy to allow the second student to do a disproportionate amountof the work, and the second student may oblige. Peer evaluation canlower the grade of the first student, but this student may not be dis-satisfied with a lower grade. The presence of enhancement pointsin the original project assignment exacerbated this problem.

As a second example, group programming projects do not nec-essarily require resource sharing. In many of the small groups in myclass, one student became adept at using the graphical user interface(GUI) toolkit (Motif). Other students in the small group mightnever have to do anything with this toolkit, since they could rely onthe expertise of the GUI programmer. This deprives the othergroup members of knowledge of the windowing toolkit, and alsodeprives the GUI programmer of the fundamental graphics knowl-edge necessary to pass the class. Rather than sharing resources, stu-dents were encapsulating them. This type of interaction is desirablein industry where everyone cannot be an expert on everything, butis not desirable in a learning environment where fundamentallearning objectives of the class were not being met by all students.

The structure of interaction, which is desirable for cooperativelearning, is represented in Figure 1. There is interaction betweenevery pair of members of the group.

A. Programming as a Group Writing ProjectAs a group assignment, creating a computer program is similar

to writing a term paper in many aspects. Having a group write aterm paper together is the assignment that has been identified as

the least effective cooperative learning assignment.12 To understandwhy this is so, examine four models for group writing.13

In the Sequential Model, the first author writes a complete doc-ument, subsequent group members edit the document in sequence.Notice that the first author is, in all likelihood, allowing subsequentgroup members to socially loaf. If this model is applied to a pro-gramming project, the first author is doing almost all of the work.Subsequent edits will be unlikely to be made since few students willmeddle with a working programming project. As a result, no coop-erative learning occurs.

In the Stratification Model, each student takes on one role. Theinitial assignment goes to the project manager. The project manag-er asks the data gatherer to collect and summarize data. These datago to the writer or editor who actually writes the document. Anoth-er team member incorporates graphics resulting in a finished prod-uct. This method again results in little resource sharing, e.g. thedata gatherer may learn little about how the graphics person select-ed and created the figures and the graphics person may not learnwhere the data gatherer found the information. It also has a un-equal division of labor, particularly if applied to a programmingproject, which will be likely to result in social loafing. The interac-tions in both the Sequential Model and the Stratification Modelare shown in Figure 2.

The Horizontal Division Model takes a large project and breaksit into separate pieces of approximately equal size. These pieces arethen accomplished separately by individuals in the group and com-bined. This model is similar to a common industrial software engi-neering process. As with the other models, there is little resourcesharing going on. The difficulty of combining programming seg-ments into a cohesive whole is also substantial, particularly whenindividuals have little experience with team programming, resultingin substantial transaction costs. If the sizes of the separate pieces arenot comparable, social loafing may also result. Figure 3 is a diagramof the interactions in this model.

The Group Composition Model, which is used by groups oftwo, has both members sitting at the computer writing the paper.This has the proper structure of interactions, except that the sizes ofsmall groups are too small for cooperative learning to occur. Figure 4shows a diagram of interactions in this model. Notice that this is the

88 Journal of Engineering Education January 2001

Figure 1. Desirable group interactions for cooperative learningform a complete graph.

Figure 2. In the Sequential and Stratification Models the groupinteractions are sparse.

Figure 3. In the Horizontal Division Model the group interac-tions are also sparse.

Page 5: Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

only model used here that has a good structure for cooperative learn-ing, i.e. the structure of interactions represents a complete graph.

The result of this analysis is that group writing assignments,whether they be term papers or programming projects do not resultin cooperative learning. This does not mean that these assignmentsshould not be given in a software engineering class where usingmodern software engineering processes (which are largely grouporiented) is the essential learning objective. In fact, transaction costsand social loafing in small group work is part of the experience ofevery practicing software engineer and therefore should be includedin his or her training. In classes where learning to perform softwareengineering in groups is not a central learning objective, however,this type of assignment will not result in cooperative learning.

B. Selecting Assignments: The Three S’sA good structure for cooperative learning assignments has been

developed by Michaelsen.14 He recommends that all cooperativelearning assignments be characterized by “The Three S’s”:

● Same problem● Specific choice● Simultaneous report.An example of an exercise that has all of these attributes is a sin-

gle multiple choice question given to all groups. When the time al-lotted is finished, the groups should report their results by eithershouting out their choice to the class or holding up their choicewritten on a piece of paper. Class discussion of the question canthen focus on the choices made by different groups. The competi-tion between groups to give the most common answer, particularlyif there are several answers of differing degrees of correctness, is in-tense and results in a lively intragroup discussion. When the groupanswers are compared in class discussion, everyone in the class iswell prepared to vigorously defend their response and the class dis-cussion is intense.

A simple, factual multiple choice question will not generate thistype of discussion. To get a good discussion, one needs to focus onhigh level learning objectives in the Bloom taxonomy15 such asanalysis, synthesis, and evaluation. Low level learning objectivessuch as knowledge, comprehension, and application will not createmultiple choice problems which are challenging enough to generatethe interchange of ideas and sharing of resources which character-izes successful cooperative learning assignments.

My original group programming project with enhancementshad none of the three S’s. The groups were working on slightly dif-ferent problems because of the enhancements. Although they weremaking hundreds of choices in implementation, most of thesechoices were made by individuals instead of being the product ofthoughtful collaboration. There was no simultaneous report sincethere was no single choice that was a product of the collaboration.When the enhancements were removed from the project, the as-signment had only one of the three S’s. The structure of the assign-ment led to the failure of group programming assignments in myclass.

Reference 4 offers a summary of ways in which faculty memberscan cause small group learning to fail in their classroom, particularlywhen used in combination. Their list includes the following items:

● Structure the group assignments so that students can workindependently and get the job done.

● Assign four or more cases or written reports.● Give no group examinations.● Use the absolute minimum of class time for group work.Each of these items is directly related to the structure of the co-

operative learning assignment. A group, which has to make a spe-cific choice, cannot have individuals working independently unlessit simply divides up the problems amongst its members. Since thisprocess is occurring during class time (as it must be for simultane-ous report to occur), an instructor can easily spot this aberration bythe absence of communication and suggest interaction. No grouphas ever chosen to work this way in my class.

Written reports are missing two of the three S’s, just as groupprogramming projects were. Since group examinations are one ofthe easiest and most effective ways to create learning activities thathave the three S’s, failing to give group examinations may meanthat sub optimal assignments are being chosen. As mentionedabove, the three S’s require a significant amount of class time to beused for group work. As a result, each of these items identified as apotential problem with small group work could be avoided if thethree S’s had been followed.

V. A BETTER ASSIGNMENT

In the spring of 1999, I had another opportunity to teach CS4053/5053. Instead of using group programming projects to meetthe industrial demand for students who had experience workingwith teams, I elected to create in-class assignments which wouldgenerate cooperative learning. Groups were created exactly as theyhad been previously with only one alteration. Each student wasasked to describe himself or herself as either an introvert or an ex-trovert, using the Myers-Briggs definition. This addition was madeafter it was observed that several dysfunctional groups from the firstclass consisted only of introverts, with the most problematic groupof people being so shy that they would not turn their chairs to faceeach other during discussions. The vast majority of my students la-beled themselves introverts. The few extroverts whom self reportedwere distributed throughout the groups to maximize diversity.Good fortune provided one extrovert for each group this semester.Had there been a shortage, as might be expected, I would have leftthe small group with the strongest individual student(s) without anextrovert.

The structure of the assignments was built to have all three S’s.For each major topic, a multiple choice quiz was created which re-quired that students meet high level learning objectives to answercorrectly. These quizzes typically had six to eight problems. Stu-dents first took the quiz as individuals. Then the students took thesame quiz as a group. The individual and group quizzes made up40% of the grade each. The remaining 20% of the grade camefrom peer evaluation. After the quizzes are finished, the class dis-cusses the correct answers collectively, when time permits (timingthe multiple choice quizzes has been a problem since they alwaystake substantially more time than it seems they should). This exer-cise takes an entire class period. This assignment has all three S’s

January 2001 Journal of Engineering Education 89

Figure 4. In the Group Composition Model, the structure of in-teractions is a complete graph. This model does not generalize tolarger sized groups.

Page 6: Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

and has been very effective in generating intense intragroup dis-cussion, as well as productive class discussions. This structure ofsmall group work was pioneered by Larry Michaelsen at the Uni-versity of Oklahoma College of Business. Individuals workingalone have been averaged 4/8 questions correct on the quizzes.Small groups averaged 7/8 questions correct.

This assignment avoids the two best known problems withsmall group work: social loafing and transaction costs. Social loaf-ing is severely punished in this format since individuals lose pointsboth on their quiz and on their peer evaluation. These two elementstogether make up 60% of the grade on group work. This is a power-ful incentive to be a productive individual and group member. SinceI prowl the room listening in on group discussions during the groupquiz taking process, I can also identify social loafers. With so manystudents actively engaged, spotting disengaged students is easy.When confronted with a pointed and public professorial commentabout apparent disengagement, many students will confess thatthey were socially loafing. I did not find the same individual disen-gaged twice. Transaction costs are also avoided since all group workis occurring during class time. There is no additional student timespent arranging and attending meetings. Groups that containmembers whose busy schedules preclude meeting outside of classare neither disadvantaged nor resentful.

During the course of the term, I’ve made a few small correctionsto the initial plan. The early quizzes were done with closed booksand notes. After the second quiz, students requested that thequizzes be open book and notes. As the quiz questions require stu-dents to meet high level learning objectives, and are therefore can-not be answered easily by reference to the book, this request wasgranted. This improved the quality of intragroup discussion signifi-cantly since students could read and interpret the text to reinforceand correct their arguments.

When small groups were first assigned, the same team buildingexercise was performed as in spring 1997. Five quizzes were given.The first quiz grade was not recorded or counted because a secretar-ial error caused some students to have missing pages in theirquizzes.

A. ResultsMy subjective evaluation is that students enjoyed this form of

small group work, and learned more about computer graphicsusing the improved assignments. A direct comparison of final ex-amination scores was not done since other factors in the class hadchanged significantly (e.g. the textbook, the class size, the teachingassistant structure). However, fewer students dropped and failedthe class.

There were no student complaints, and no dysfunctional groups.I did not have to schedule a single group counseling session. Thepeer evaluations were strikingly different than with the previousformat. Almost every group divided points nearly evenly. Therewere no student complaints about peer evaluation, and no studentrequested that their evaluation be changed. When students are inmy office asking questions about the programming projects, whichwere done individually instead of collectively, they were clearlymore knowledgeable about the topics and the questions were morefocused and of higher quality.

I’ve received a substantial quantity of informal verbal and emailfeedback from students. Several students commented that they feltlike they are “a real part of the class” instead of being a passive ob-

server. One student emailed that he had never “fit in” to computerscience, and that working with this group has allowed him to seethat he could. When asked for informal feedback on the coopera-tive learning exercises, students consistently commented that theycouldn’t pass the class without the group quizzes. There was palpa-ble excitement on the days quizzes are given. Students were ontime, and immediately engaged. After class was over, members ofgroups were often seen continuing to discuss class material in thehallway, sometimes for extended periods. From the student per-spective, this experiment was a success.

The only significant difficulty reported by students was thatreading the text independently, as is necessary to pass thequizzes, is difficult. This may be caused by the shortage of com-puter science texts that are both technically correct and pedagog-ically well designed. Since the rapid pace of change in computerscience often precludes the creation of these definitive texts, thisdifficulty will probably continue. In other engineering disci-plines, where these definitive texts are more frequently available,this form of cooperative learning would be expected to work evenbetter.

From the professor’s perspective, this assignment has been suc-cessful. Class discussion after the quizzes was directed towardsareas where students are having difficulty and was therefore moreproductive. The quality and quantity of class discussion alsochanged. There was more student interest and focus, and studentsare asking more sophisticated questions and bringing up subtleand interesting points. Although I initially feared that the breadthof coverage might have to be sacrificed for depth of coverage, thishas not been the case. My explanation for this is that students arespending more time outside of class studying the book and notes.This decreases the amount of class time that must be spent intro-ducing elementary material, which is undoubtedly the least pro-ductive use of classroom time.

On the negative side, substantial faculty time must be spent cre-ating quizzes. Although this will probably improve as I becomemore experienced in asking questions which represent high levellearning outcomes in multiple choice format, I expect that it will al-ways take more time than writing a simple lecture. Of course an in-significant amount of time is spent on grading these quizzes, whichis partial compensation. It is my opinion that the gains in studentlearning are significant enough to justify this investment.

An interesting anomaly occurred during the first two weeks ofthe semester. Enrollment for this class has typically been large, ini-tially in excess of eighty students in spring 1999. When the collabo-rative learning exercises were explained to students in class, morethan twenty students elected to immediately drop the class. Thisleft me with a class size of only fifty-two students. Most of the stu-dents who dropped were international graduate students. Whenasked why they dropped the class, the most common response wasthat it “seemed like it was going to be too much work.” This is simi-lar to students “voting with their feet” and taking a biology class inthe standard lecture format instead of the cooperative learning for-mat.16 In the Spring 2000 computer graphics class, which is cur-rently underway, only a handful of graduate students dropped theclass. My explanation for the difference between spring of 1999 and2000 is that many concerned graduate students were able to seekreassurance from students who had taken the class previously thatthe group work was not going to be a big problem or adversely af-fect their grade.

90 Journal of Engineering Education January 2001

Page 7: Progressing from Small Group Work to Cooperative Learning: A Case Study from Computer Science*

VI. CONCLUSIONS

There is little doubt that the industrial demand for engineersand computer scientists who are experienced in small group workwill continue to grow. This places demands on academe to findgood ways to give students experience working in small groupswhile retaining or improving the intellectual content of courses. Byimproving the structure of a cooperative learning assignment in mycomputer graphics course, I have given students the chance to de-velop skill in working with small groups without sacrificing cover-age of the material or creating unpleasant and unproductive learn-ing environments for students.

ACKNOWLEDGMENTS

My interest in small group learning was generated, fostered, andsupported by the Instructional Development Program at the Uni-versity of Oklahoma, headed by L. Dee Fink. The dual multiplechoice quiz format model is from Larry Michaelsen of the Univer-sity of Oklahoma Michael J. Price College of Business.

REFERENCES

1. Felder, R.M., “Random Thoughts…We Never Said it Would BeEasy,” Chemical Engineering Education, vol. 29, no. 1, 1995, pp. 32–33.

2. Black, K.M., “An Industry View of Engineering Education,” Journalof Engineering Education, vol. 83, no. 1, 1994, pp. 26–28.

3. Lang, J.D., et al., “Industry Expectations of New Engineers: A Sur-vey to Assist Curriculum Designers,” Journal of Engineering Education, vol.88, no. 1, 1999, pp. 43–52.

4. Feichtner, S.B., and E.A. Davis, “Why Some Groups Fail: A Surveyof Students’ Experiences with Learning Groups,” The Organizational Be-havior Teaching Review, vol. IX, issue 4, 1984–1985, pp. 58–73.

5. Brickell, J.L., et al., “Assigning Students to Groups for EngineeringDesign Projects: A Comparison of Five Methods,” Journal of EngineeringEducation, vol. 83, no. 3, 1994, pp. 259–262.

6. Hunkeler, D., and J.E. Sharp, “Assigning Functional Groups: TheInfluence of Group Size, Academic Record, Practical Experience, andLearning Style,” Journal of Engineering Education, vol. 86, no. 4, 1997,pp. 321–332.

7. Tonso, K.L., “The Impact of Cultural Norms on Women,” Journalof Engineering Education, vol. 85, no. 3, 1996, pp. 217–226.

8. Felder, R.M., et al., “A Longitudinal Study of Engineering StudentPerformance and Retention III: Gender Differences in Student Perfor-mance and Attitudes,” Journal of Engineering Education, vol. 84, no. 2,1995, pp. 151–164.

9. Lerner, L.D., “Making Student Groups Work,” Journal of Manage-ment Education, vol. 19, no. 1, 1995, pp. 123–125.

10. Felder, R.M., G.N. Felder, and E.J. Dietz, “A Longitudinal Studyof Engineering Student Performance and Retention V. Comparison withTraditionally-Taught Students,” Journal of Engineering Education, vol. 87,no. 4, 1998, pp. 469–480.

11. Zin, Q., D. Johnson, and R. Johnson, “Cooperative Versus Com-petitive Efforts and Problem Solving,” Review of Educational Research, vol.65, no. 2, 1995, pp. 129–143.

12. Michaelsen, L.K., L.D. Fink, and A. Knight, “Designing EffectiveGroup Activities: Lessons for Classroom Teaching and Faculty Develop-

ment,” published in To Improve the Academy, New Forums Press and theProfessional and Organizational Development Network in Higher Educa-tion, vol. 16, 1997, pp. 373–398.

13. Schulz, K.H., and D.K. Ludlow, “Incorporating Group WritingInstruction in Engineering Courses,” Journal of Engineering Education, vol.85, no. 3, 1996, pp. 227–232.

14. Michaelsen, L., “Three Keys to Using Learning Groups Effective-ly,” published in Toward the Best in the Academy, a periodical published byThe Professional and Organizational Development Network in HigherEducation, vol. 9, no. 5, 1997.

15. Bloom, B.S., Taxonomy of Educational Objectives. Handbook I: Cog-nitive Domain, David McKay Co., 1956.

16. Miller, J.E., and J.E. Groccia, “Are Four Heads Better Than One?A Comparison of Cooperative and Traditional Teaching Formats in anIntroductory Biology Course,” Innovative Higher Education, vol. 21, no. 4,1997, pp. 253–273.

January 2001 Journal of Engineering Education 91