Notes on Study Groups

These are my notes on study groups: what appears to make them work, and some topics that we have covered in the Ptolemy study group.

We have been running a study group for a few months now, with topics mostly (for now, at least) chosen from various fields of software development. We have looked at various aspects of UML (Unified Modeling Language), object-oriented design patterns, and formal software inspections.

Participation in the study group is voluntary. This presents some challenges for the moderator in encouraging interest and participation.

Moderating a study group

In my view, the prime measure of a "successful" study group is that each participant feels that they got something out of it. Here are my thoughts on what can make this happen:

Choosing a topic: relevance, concreteness, acheivability

Topics need to be something that all participants could conceivably use, if not right now, then sometime. In the same vein, concrete and "hands-on" techniques are more likely to be relevant than abstract or hypothetical ones.

To get the most out of a meeting, participants need to do some preparation -- this always makes progress faster and the discussion more lively. To encourage this, the reading material needs to be short enough to be read and understood fairly rapidly. Ten to fifteen pages, although small, nonetheless seems to be a good size for a study group of this kind.

I think participants are much more likely to join and enjoy the study group meetings if what they get out of it is large relative to what they put into it.

Moderating the meeting: focus, openness, and enthusiasm

The purpose of the study group is to study something new. To aid this, the moderator should encourage a "we are doing it by the book" approach, solely for the purpose of enabling understanding of new ideas without premature rejection.

If a participant disagrees strongly with ideas presented in the reading material, the moderator needs to steer the discussion away from subjects that cannot be verified directly from the reading material. A participant with a strong dissenting voice should be encouraged to find suitable reading material to present at a later study group.

The moderator does not need to be an expert in the topic -- in fact, I think meetings work better if the moderator is also learning the material for the first time (although perhaps having done more background research than the others), as this avoids any possibility of the meeting turning into a lecture.

Meetings that focus on the topic and material at hand seem to move faster and be more satisfying than those that wander off into other areas.

Finally, a moderator who is is excited about the topic he has a much better chance of inspiring the other participants into, um, participating. I have found this surprisingly difficult to maintain. The moderator also needs to encourage an open and non-threatening environment, and to be (genuinely) excited about the input of the participants.

Participation

The best way to encourage participation in the meeting is to build it into the meeting's structure. Here are some techniques that appear to have worked so far:

1. Take turns in presenting. Each person is assigned a small section of the reading material, and presents it at the meeting. We used this technique to cover object-oriented design patterns, where we covered seven patterns over the course of two meetings.
2. Passing the marker. People have the whiteboard marker passed to them and are in control of what goes on the whiteboard. This more-or-less forces each person in turn to take an active role in the discussion. This works particularly well if the topic is about or includes visual notations -- drawing the notation on the white-board gives participants a useful "first step" that overcomes the natural resistance to learning yet-another notation.
3. Role-playing. Each person assumes a well-defined role and plays it out in the meeting. This worked well for the software inspection meetings, in which people were assigned roles such as moderator, scribe, reviewer, and so on.
4. Round-robin. This tends to be a last-ditch attempt to get people involved. If the topic has a list of some kind, taking turns around the table to assess, explain, or just read each element of the list is better then the moderator doing all the talking!

Another technique is to have a case-study. Case-studies are a little difficult because a) it is diificult to find case-studies that are relevant yet small enough to be covered in a single meeting, and b) it is difficult for the moderator to get someone to provide a case-study and for the others to read it prior to the meeting. Nonetheless, when it can be done, a case-study provides a useful incentive and relevence to the meeting.

A key point to remember in all meetings is the whole purpose: to learn something new. It is important not to be distracted by a case study or the broader context in which the meetings take place (a research project) into turning the study group meeting into a design or technical meeting. The purpose of the study group meeting is to learn -- any by-products, such as design insight into the current project, that happen to be useful, are great, but must be seen as purely accidental.