How do you deal with Lone Rangers in group projects?

Question

We all have them - students who want to write all the code themselves, who don't want to be part of a group project. They have poor social skills, or they don't know anyone else in the class, or they don't trust others, or they think other people "slow them down". So they go home after a group project is assigned, write all the code themselves, and bring it back to the first group meeting, completed.

A typical situation is a group project done in a class or lab period over several days. The instructor or a lab assistant is present to watch over the students and give advice as needed. Different strategies might be needed if the project is done outside the view of faculty on the students' own time.

This could also differentiate depending on whether the situation is the first occurrence (you are surprised by it), or if you are familiar with the Lone Ranger and know he or she has a history of going rogue.

What are your practical ideas for preventing a student from taking over a group project, or dealing with it after it has occurred?

---

Of note from other posts:

Reading the answers to Techniques for encouraging pair programming and What advantages/disadvantages have you seen with Pair Programming in the classroom offers insight into the problem of encouraging students to actually "work" together, which can be part of the problem here. The real issue, however, isn't that the other students aren't willing to do the work, rather that the Lone Ranger just does all the work, usually before work begins, without the others even having the opportunity to work.

Two other questions, Is it possible to ensure division of labor on a group assignment?, and Problematic student at a very high level, help with creating the environment and assignments to enable group work, and determining if someone has gone rogue and done all the work. Neither deals with preventing the Lone Ranger from repeating once the problem has been identified.

Answer 1

This is really a separate approach from my first answer, which has received some push-back.

It's worth noting that many of these loners are simply students who are substantially ahead of the curve. One way to really want to engage such students in pair programming is to pair them with each other. This will create something of a Dream Team.

Give them the assignment, but tell them that their goal is to produce the coolest thing that they can that utilizes the concepts that the lab is developing within the time before the lab is due. Tell them you're excited to see what they can come up with, that you'll allow them to present their work to the group at large, and that if it's a cool enough idea, you may use it as a launching point for a future lab for later generations of students.

As an aside, there is no reason to restrict this approach to the high-fliers. It can be reasonable to allow students to propose modifications to the labs if these modifications excite the students. It involves more work on your end, but you'll get better output and (more importantly) more engagement and buy-in from your students overall.

Answer 2

I might push back against the core idea here, and this gets to the idea of the central mission of the course of study. Within my course, teamwork is not a primary goal upon which I will assess my students. This is not to say that I don't value it. I think that there is great value in paired programming, but I approach this only as a salesman, not as a taskmaster.

I get real buy-in. On my most recent lab, >85% of my students have opted for two people, one-screen, driver/navigator paired programming.

That said, I never require paired (or group) programming. I allow students to opt into paired programming if they wish to, and I sell it like crazy, but for some of those Lone Rangers, the idea of working with another person can be intensely frustrating. Where this becomes a big problem is where they begin to hurt the education of their peers by simply doing the work themselves. Some of these students may never really warm to the idea. While I want to teach good team-working skills, I am unwilling to jeopardize the education of my middle- and low-flying students in order to force the high-fliers into an activity that they really don't want to engage in in the first place.

Even in this environment, there can still be group projects, but they would involve differentiated responsibilities:

Person A is responsible for parts 1, 2, and 3 of the project, while Person B is responsible for parts 4, 5, and 6. Person C is responsible for QA. Design your APIs together, and get them approved by me prior to the start of any actual coding.

Answer 3

Most of what I was going to say was covered by @Buffy. Also I have not tried this in the classroom yet. It is some ideas that I had, based on my industry experience. Pick and choose what seems right, and test it.

Do it agile one requirement at a time.

• You can write the unit tests for them, and release one test at a time. Some automated system, that releases the next test when a test passes.

• Use revision control, tell them that they must check in regularly, at least after each test passes. Ensure that they can only check-in code form within the lab. Create an auto grader that checks out there code one revision at a time, and runs the units tests. Check that they don't do to much per commit. Be careful as if they are doing it correct, with well written code, you can get emergent behaviour, and several tests will suddenly pass (Maybe 3 then 1 then 10 then all).

• Get the high performer writing automated tests.

---

Ideas added by others:

• “Get the high performer writing automated tests.” - or other tooling. Writing tooling that saves time for other contributors is a nice skill to have, it suits lone rangers well (since the tooling is often smaller in scope and suitable for a single person), and naturally forces personal interaction - their peers have now become their clients. – Logan Pickup

Answer 4

Since I first considered posting this question, the situation played out in my classroom, and here's how I handled it. I had three students who had a history of "Lone-Rangerism" (last semester). I assigned the group project and warned the entire class that no one could go rogue. I observed each group frequently, circulating the room every 5-10 minutes, paying special attention to those groups who had a former Lone Ranger on their team, making sure that their project wasn't suddenly "done" from importing code the LR did at home. I also set a timer and made each team change "drivers" every 30 minutes so that the Lone Ranger couldn't take over and do all the work. So far, so good.

Answer 5

As suggested in a comment, I'll add the following.

The purpose of an education goes beyond the learning of narrow technical skills. If you graduate with that, but nothing else you probably don't have a very bright future other than via some serendipity. There are rare exceptions of course, but for every "creator of a major OS who has people issues" there are likely thousands of others who are isolated in their lives and unemployable.

Both the Prima-Donas and the total introverts (even the autistic) need to have a way to grow personally as well as professionally during their school years and CS instructors can't just leave it to someone else. Your job is to educate your students, not just present them with technical details. Part of the education of any professional today is learning how to work well in team situations. That is the purpose of student teams. It is not (NOT) the more efficient production of some software.

So, you need a way to give the social outliers a way to learn those skills, even if their natural tendencies lie elsewhere, and even if they don't do as well at socialization than at tech. They have to start and they have to advance.

Furthermore, pairing like with like is sub-optimal: Homogeneity doesn't let them grow. If your superstars only work with other superstars they won't really learn much and might fight like cats and cats. At the other end of the scale (the extreme introverts) I predict long, unproductive, silences. People need to learn to work with people not like themselves - variety is the chocolate-of-life. Both of those traits limit the individual and both can be overcome. One of the best public speakers I know and an inventor of an important programming language is extremely introverted. He taught himself to overcome his "handicap" by playing a role when needed, not by changing his personality. My personal case is different. I am, by nature, very introverted, but have actually changed my personality and few, other than my spouse, recognize that introversion. I did it by forcing myself out into the open and then deciding that the consequences weren't as dire as I'd expected. Your personality isn't deterministic of what you can do, just how hard it is to do some things. But teachers need to help students, especially young students, deal with this.

That said, in a team, it is possible that different people take different roles. It is best if you can find a way for them to switch roles (and in pair programming it is essential that they do so), but it may not always be possible or worth the disruption.

One option is to make your superstars tutors or teaching-assistants. If your project has roles, give them a non-programming role, since they won't learn much from just programming if they already excel there. Or give them a tester role. Or a tool builder role. But best if they can also learn to work with others. As a tool builder the rest of the team becomes their customer, similar for tester. They have to interact, but can't just take over. Their role may not require intense interaction with everyone else, but it does require some. Roles like this also confer responsibility on the individual while permitting them to do their own thing up to a point.

Teach the whole person, not just the geek. Expect that they are all different, with different strengths and weaknesses. Your job isn't to "fill them up", but to "change their brains."

Answer 6

My answer is "play it by ear", and don't expect to make any progress.

Example 1: myself I was one of those LR students decades ago. Grades and peer approval had no meaning to me. There were no levers for a teacher to pull to get me involved. I pulled in C grades, yet scored 100% on the standardized provincial physics exam in 12th grade.

I recently found out that I am (by this year's standards) autistic, in addition to being ahead of the curve by a significant amount. I either ended up doing all of the work for "team" projects, or got shuffled to the side because I had no interest in the drama that went with dealing with people. No amount of teacher intervention or classroom technique changed that.

Example 2: My daughter My daughter was part of a group assignment in her media class. When one of her team mates started texting her inappropriately, she and her team mate were informed that she was doing her assignment solo. The teacher was puzzled by the sudden unilateral change, but he wisely chose to trust that this was necessary.

Edit: I missed the point Based on comments (thanks @Buffy) I realized I totally failed to make my point. The two real-life scenarios I describe are personal experience, and are not extreme. My own autism has not stopped me from having successful careers, and would have remained undiagnosed until my passing had I not had other health issues in which it was found.

Without the background information I provided here that was not available 4 decades ago, my high school teachers saw me as having "advanced academics" and "poor social skills" etc, and "would do the task over night to bring it back to the first group meeting, completed".

At that time, autism wasn't even on the books as a legal diagnosis. It was years before it was recognized as being biological in origin. Today, I understand that the point of the tasks was the group experience rather than the task itself. But without that explicit explanation, I was physiologically not capable of realizing the task was not the important part of the assignment. Furthermore, had I been told that the "group" was the important part, I would have simply shut off rather than participate.

While not all kids with poor social skills are autistic, when I see the combination of poor social skills and advanced academics, I raise the question because of my own experience.

Likewise, without the background information, my daughter's teacher's perception would have been that an advanced student suddenly went rogue without explanation. The texts were mistake of the young man's that both found terribly embarrassing, and neither were prepared to talk about with a teacher. He (the teacher) may still be under the impression that she got tired of being slowed down by a novice.

As a teacher you don't have all of the information, and all you can do is the best with what you have.

Edit 2: What can you do??

As suggested by @beni , I have some suggestions that might help.

I find it almost as ironic that I am making recommendations centered on "soft" skills as I do that in my volunteer time I manage a team of (mostly) adolescents in the high pressure and close quarters of live webcasting.

1. Understand that part of learning to work in a group is learning when to leave the group unilaterally. In my daughter's case, she learned that sexual harassment is not an acceptable part of team work, and it is perfectly okay to walk away from a team where it is happening. Recognize that interpersonal conflicts that are irreconcilable do happen between high school students, they need to try to handle some things on their own, and you will not always know about those issues.
2. Recognize that there is no cure-all solution. Setting an advanced student with good social skills (like my daughter) up as a team lead or teachers assistant can work well, but setting up and advanced student with no interest in socialization (like myself) in that role would precipitate a shutdown or walk out if you were lucky.
3. Recognize that some tech companies are now specifically seeking programmers on the autism spectrum , precisely because they can solve certain classes of problems better than teams of neurotypical programmers. Being unable to work in a group is not necessarily a handicap. (https://www.windowscentral.com/microsofts-autism-hiring-program-seeks-bring-diverse-talent-redmond)
4. If your problem students share the characteristic of being hyperfocused and task-centric, put them together. They may go home and bring the task back completed for the first official meeting, but being similarly focused they are likely to strike a synergy and do it together (that would be me!). At the very least, they will have a chance to review each other's solutions and time to expand. Being task centered, they may not socialize much outside of the task, but they can develop a feedback loop of excitement as they expand and improve the solution.
5. Don't treat students you don't understand as damaged goods. I have a gentleman on my webcast team whose teacher tries to meet him half-way by treating him like an infant. This kid (middle school) has earned sufficient respect as a camera tech (following directions) and a technical director (giving orders) during live webcasts that when he gives directions everyone on the team pays attention, including people twice his age or more. His teacher has nothing but frustration with him ... doh!
6. Engage their interests with specialization. If I chose to do something in school, it was out of synergy with my own interest. I could do relativity physics in my head, but wouldn't do homework. In one class I got a final grade of 10%, because I scored 100% on the final exam that was worth 10% of the class grade.

Another member of my webcast team is autistic to a higher degree than I am, but this kid (not old enough to drive) gets himself up every Sunday and rides his bike to church so he can do his part on the team as title artist. It suits him because he sits in a quiet corner away from the rest of the team and can focus on his artwork. He's started to earn respect from his peers because when he's not there they have to do that job. Modern software development requires a broad range of specializations - take advantage of it.

7. Make use of remote team management tools and practices. Today, in industry, many software project teams never meet in person. My own team includes people from all over the USA, Brazil, and India. On some of my most productive days I never actually leave my bedroom. Teamwork does not require face to face time.

Answer 7

The key to this is to use a carrot and not a stick. Even better, build the carrot into the project process itself, so that the incentives for the superstar are to do the right thing. Of course you should always try to align the incentives with the desired outcome, but here it needs special care. It is applicable even if you don't have a Lone Ranger too.

Your objective, in the project is not, I assume, code at the expense of all else. Learning is the objective, not code. This is different from the workplace. Here the #1 goal is not working code, but learning. Even well structured code is valued above working code in education, and the structure will likely lead to correctness of the code in any case.

First, in your project description, say something about the learning. And divide up the grade for the project into parts, heavily advantaging process and good behavior: team-work. One way to achieve that is to have the students give reviews of their peers at the end of the project (and to advertise this at the start). You also need to give explicit grades for cooperation and teamwork.

One possible way to get feedback and give students a way to feel proud of their contributions is like this. Give every student three, say, "chits." These can be index cards signed by both yourself and the student. Each student is permitted to give a chit to another student based on their helpfulness. The receiver also signs the chit, say on the back. At the end of the project collect the chits and reward people based on how many they have from other students.

Another method, if teams have about five students or so, is to require each student to fill out a form on which they list the three, say, students who were most helpful and contributed the most to the project. They also need to write a line or two of explanation for each "vote". Note that they don't evaluate every student, just the ones they think should be rewarded.

If teams are always just two students, then each can be required to write a bit about their partner's chief contribution and their own. Again, you aren't asking for negatives and are less likely to get them in most cases anyway.

These peer-review techniques should be introduced before the project starts, so students know what is going on. I have learned interesting things about some students this way when I'd have overlooked positive contributions of someone.

Another help is to teach a development process along with the project and insist that it is used. An Agile process is especially helpful here since you can act as the team's "customer" and only give them enough "stories" (work to do) for a single period, rather than the project as a whole. You can even warn them that the direction of the project (the requirements) may change over the course of the project. There is no incentive to program speculatively in this sort of environment.

Each day, you need a set of index cards, each describing some feature of the project to implement that day. Pass them out to the team(s) and hold a short question/answer session to clarify what is on the cards but not to make a complete specification.

If you want to really make it work, have them write unit tests for the things they build, so that they know when it "works" according to the tests. Expect questions throughout the session, since the specification is only in your head.

If there are several cards for each day, then pairs (paired programming) can switch roles at the completion of each card. Even better is to have them switch for each test. Student A writes a test and passes the keyboard to B who makes it pass. B then writes a test and passes the keyboard back to A. The one not typing (the navigator) isn't expected to sit silently, but to offer suggestions throughout. Your superstar may wind up teaching some others a bit about the technology this way.

Answer 8

A suggestion would be to include in the project grade a component that evaluates collaboration and make it so a group with a lone ranger fails the project or is assigned a barely passing grade. Make this explicit the moment the project is proposed, emphasize it during its execution and explain how they will be evaluated in this regard. For instance, the University of New Orleans published a collaboration rubric that can be readily used by the instructor (or students) to evaluate the collaboration abilities of a student.

If possible, ask students themselves to evaluate the how well their partners collaborate. There is some scientific evidence (1, 2) that peer assessment activities can be beneficial to grade individually according to participation in group projects. These papers also contain rubrics that could be adapted to your context.

It is important to communicate to students that collaboration means doing what is best for the team, not doing tasks physically together. If the objective of the team is learning, completing a project alone without any input from the other members is not what is best for the team, so it is not good collaboration. However, completing, individually, a task that is valuable for the team and synchronizing its execution with the rest of the work is good for the team, so it is good collaboration (as pointed out by @pojo-guy's answer). The key here is not individually, but valuable for the team and synchronizing.