One row per slide, to glance at while the deck is on screen. The reasoning behind every answer is in the sections below. Deck: /deck/group-dynamics/main.pdf.
| Slide | On screen | What you fill in or say |
|---|---|---|
| 2 | Start here | Disagreement is normal. A group that never disagrees is dominated by one person or not engaging |
| 3 | Four kinds, and what each one needs | Fact: check the source. Approach: try one and revisit. Priority: the chair decides. Effort: raise it in a meeting, as observable facts |
| 4 | The framework | Listen, restate, identify, choose. Restate is the one everybody skips |
| 5 | Scenario 1 | Approach. Try one and revisit; record the trial and the review point. Watch for groups resolving it by seniority |
| 6 | Scenario 2 | Fact, so the easiest kind. Write a test that separates the two claims. Two minutes, against the ten it took |
| 7 | Scenario 3 | Effort. The private messaging is the part to pull out: D cannot answer it and the minutes cannot record it |
| 8 | Effort: say it like this | Observable fact, not character judgement. In a meeting, not outside one |
| 9 | The chair, every week | Round-robin the discussion; check each decision one member at a time. Say that both feel artificial at first |
| 10 | When it stalls | Break, try both, defer to the chair, write it down. It goes in the minutes either way, resolved or open |
| 11 | This week's Python | Objects, and a terminal and an editor. Read on your own |
| 12 | What is self? |
The instance the method was called on. Python passes it for you, which is why it is in the definition and not the call |
| 13 | Does your project need a class? | No. A library of plain functions is marked the same. A class earns its place when functions keep passing the same things around |
| 14 | Out of the notebook | cd, ls, python main.py. A notebook remembers what you ran earlier; a file does not |
| 15 | Before you leave | The disagreements and decisions box; rotate chair and secretary; Week 5 minutes to the next session |
A full session. Roughly: 10 minutes on the categories and the framework, 20 minutes on the three scenarios, 8 minutes on effort, 8 minutes on the chair's two practices, 10 minutes on the Python slides, and the last 4 minutes on the closing slide.
Keep those last 4 minutes. Slide 15 is where this class's content attaches to the form: the disagreements and decisions box is the thing the whole session has been preparing them to fill in, and it is the reminder to meet this week and bring the Week 5 minutes to the next session.
If the scenarios run long, take two of them rather than cutting the Python slides. The scenarios are the kind of material that recovers in a later week; a group that cannot run its code from a terminal is stuck now.
The deck. There is a write-on deck at /deck/group-dynamics/main.pdf. The resolution for each of the four kinds of disagreement is blank on slide 3, each of the three scenarios on slides 5 to 7 has a workspace and a short blank, and the three Python slides, 12 to 14, each have a workspace for the answer the room gives. Answers are at the end of these notes.
The opening claim is that disagreement is normal and often useful, and that a group which never disagrees is either dominated by one person or not engaging with the work. Say it plainly and early, because several students will be carrying the opposite assumption.
Give the four categories (fact, approach, priority, effort) and the four-step framework (listen, restate, identify, choose). Point out that step 2, restating the other position, is the step that does most of the work, and the one everybody skips.
Then the three scenarios. Put each on the screen, give the groups two or three minutes to answer the questions among themselves, then take answers from the room:
Handle effort directly. Raise it in a meeting, not outside one. State observable facts rather than character judgements, and give them the two phrasings side by side. Then connect it to the geometric mean: the scheme is built so that neither free-riding nor carrying a group is rewarded or punished unfairly, which is why the minutes matter.
Close on the chair's two weekly practices, round-robin discussion and explicit decision checks. Acknowledge that both feel artificial at first. Saying this out loud makes groups much more likely to persist with them past the first meeting.
Then the closing slide, which does three jobs. It points at the disagreements and decisions box, so today's framework has somewhere concrete to land. It reminds them to rotate the chair and the secretary, which is the week this starts to slip. And it reminds them to meet in their own slot and bring the Week 5 minutes to the next session, the second of the five \(I\) is counted from.
Slides 11 to 14 cover the week's two chapters, objects and the command line. They are not a lecture on either: the students read the chapters themselves, and these four slides put the three things that actually catch people in front of the room.
Slide 12, what is self? Let them answer before you do. The answer
is that self is the instance the method was called on, and that Python
passes it for you, which is why it appears in the definition but not in
the call. Showing the same method called on two different instances is
the fastest way to make it land.
Slide 13, does your project need a class? The answer on the slide is
No, in large type, and it is there deliberately. Every year a group
decides it must write classes because the chapter was about classes, and
produces something worse than the library of plain functions it would
otherwise have written. A class earns its place when several functions
keep passing the same things around; say that, and let them decide.
Slide 14, out of the notebook. The three commands are cd, ls and
python main.py, and that is genuinely most of what they need this
week. The question underneath is the one that matters: the submission is
a .py file, and a notebook remembers what you ran earlier while a file
does not. Expect it works in the notebook but not from the terminal,
which is almost always a cell that was run out of order or a name that
only exists in the notebook's memory.
Send the following message before class:
Hi all,
In tomorrow's class we will look at how groups disagree, and how to
handle it. We will work through three scenarios, all of which are
things that genuinely happen in group projects in this module.
Nothing to prepare.
Please get in touch if I can assist with anything,
Vince
Send the following message after class:
Hi all,
The slides from today's class on group dynamics are on the website,
along with the fuller notes on handling disagreement:
https://vknight.org/cfm/topics/group-dynamics.html
A reminder that your minutes have a disagreements and decisions
section. Use it, including for disagreements that are still open.
Please get in touch if I can assist with anything,
Vince
Slide 3, how would you settle each one? The four blanks, in order:
Take these from the room rather than reading them out. Fact and approach come quickly; priority usually produces "vote", which is worth engaging with, since a four-member group splitting two-two is exactly why the chair exists.
Slide 5, scenario 1. A disagreement of approach: both want working tested code and disagree on the route. The resolution is to try one and revisit at the next meeting. Into the minutes goes the trial and the review point, something like "agreed to write tests first for the next function and review on Tuesday". Watch for groups that try to resolve it by seniority or by who is the better coder.
Slide 6, scenario 2. A disagreement of fact, and therefore the easiest kind. Right now they should write a test that distinguishes the two claims, or check the function against a case they can compute by hand. "It runs" and "it is correct" are different statements, which is worth saying explicitly. It should have taken about two minutes, against the ten it did take. The gap between those two numbers is the slide.
Slide 7, scenario 3. A disagreement of effort. The private messaging is the part to pull out: it feels kind and considerate, and it is the single most corrosive thing a group can do, because it moves the problem somewhere D cannot answer it and the minutes cannot record it. The right move is to raise it at the next meeting, in terms of the observable fact that the function is not written, and to record what D agrees to do before the following meeting. If it does not improve, it comes to you in the contact hour.
Slide 15, before you leave. Nothing to elicit here, but do not let it become a slide you talk over while people pack up. The point worth making out loud is that the box exists because disagreement is expected: a minutes form with an empty disagreements section every week for five weeks is not evidence of a harmonious group, it is evidence that nobody is recording what happened. Groups that write "none" every week are worth a question in the contact hour.