Peeragogy Handbook V1.0/Thinking about patterns

Authors: The Peeragogy Team

Although a grounding in learning theory helps inform peer learning projects, Peeragogy, at its core, comes to life in applied practice. For a successful outcome, take a look at these best practices, patterns, and use cases (also called case studies or examples). Patterns and use cases that co-facilitators and participants identify as the project unfolds can serve the next peeragogical enterprise as well.

What is a pattern?

A pattern is anything that has a repeated effect. In the context of peeragogy, the practice is to repeat processes and interactions that advance the learning mission. Frequent occurrences that are not desirable are called anti-patterns!

Christopher Alexander: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in a way that you can use this solution a million times over, without ever doing it the same way twice.” [1]

Patterns provide a framework that can be applied to similar issues but may be metaphorically solved in different ways, sometimes in real world or face to face events and other times in digital space / applications.

Christopher Alexander: “Can we do better? Does all this talk help to make better buildings? [...] What is the Chartres of programming? What task is at a high enough level to inspire people writing programs, to reach for the stars?” [2]

Note: the notion of the analog (such as a plaza) could become a digital metaphor for a group chat or Google+ Hangout -- a group meeting space / agora. Indeed the working title for Google Communities was "piazza!"

Patterns of peeragogy

Here is our index of the patterns we've found so far (described in more detail after the jump):

Wrapper - Front end appearance to participants. Consolidate and summarize.
Discerning a pattern - Found a pattern? Give it a title and example.
Polling for ideas - Invite brainstorming, collecting ideas, questions, and solutions.
Creating a guide - Overviews expose the lay of the land. Collecting content and stories.
Newcomer - Create a guide for "beginner's mind" and help avoid need to introduce new members each “meeting.”
Roadmap - Plans for future work, direction towards a goal, dynamic
Roles - Specialize and mix it up. Play to participants strengths and skills.
Project focus - Lightbulb moment: Most specific projects involve learning!
Carrying capacity - Know your limits, find ways to get other people involved.
Heartbeat - The "heartbeat" of the group keeps energy flowing.
Moderation - When leaders step back, dynamics can improve; moderator serves as champion and editor.
Use or make? - Repurposing, tinkering, or creating from scratch?
Reiterate - Periodically review and revise above actions as needed

Anti-patterns for Peeragogy

And some "anti-patterns" (things to avoid):

What is a use case?

A use case describes someone (or something) who uses a given system or tool to achieve a goal. A use case consists of a title, which serves as a brief summary; a main actor, and a success scenario. Additional features can be added, such as alternate interactions or choices that lead to a variation on the result.

A use case is a scenario which employs one or more persona (personal profile & role) in a situation and how she or her group works on a project/problem and their processes to come to a solution or solutions. Some activities do not have a single solution, and are often referred to as "Wicked Problems." The recorded processes can be normalized to be come standardized into use cases that can be employed literally or modified to fit the context of the activity at hand.

Use cases for Peeragogy

We also present a variety of hypothetical and not-so-hypothetical use cases:

Pattern language

Combine patterns and use cases and you start to identify a pattern language that can be used immediately, and in future projects. The next section on problem solving goes into more detail, but we'll preview the idea here with the following diagram:

The subsequent major sections of this book -- Convene, Organize, Cooperate and Assess -- represent big clusters of patterns that are likely to come up time and again in various projects (do you see the analogy with the four major branches of the diagram above?). You are of course free to invent your own patterns. Each project will tend to have it's own design, and it's own unique way things play out in practice. Here, we present these small but powerful "starter patterns".

Christopher Alexander: These ideas—patterns—are hardly more than glimpses of a much deeper level of structure, and is ultimately within this deeper level of structure, that the origin of life occurs.

EXAMPLES

The above use cases and patterns make the “story” abstract – but how about some concrete examples of peeragogy in action? Consider:

OpenHatch.org, “an open source community aiming to help newcomers find their way into free software projects.”
The Free Technology Guild is a younger project with aspirations similar in some ways to those of OpenHatch, but in this case, oriented not just to pairing newcomers with mentors, but pairing clients with service providers. “The idea is that we as a group will do useful projects for our members or external parties, and on-the-job we mentor and learn and get better.” (Since this is a new project, the project building phase is itself a nacent example of paragogy.)
Many more examples on our examples page!

References

Alexander, Christopher, Ishikawa, Sara, and Silverstein, Murray, A Pattern Language: Towns, Buildings, and, Construction, New York: Oxford University Press, 1977.
Gabriel, Richard P. Patterns of Software, New York: Oxford University Press, 1996. (Includes a forward by Christopher Alexander.)

Other related work

Cluetrain Manifesto (the First edition is available for free)
New Rules for the New Economy (you can also read the book online)