exampler.com/testing-com > Test Patterns > Workshop 1 > Schedule > Group Writing Workshops[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Different Ways People Run Writing Workshops

Here are notes from conversations I've had with various people.

Mary Lynn Manns

Break into groups of 4-6. (It's also been done with groups of up to 12.) Each group has a particular topic, possibly fairly broad. Within that topic, the group brainstorms about challenges and problems. Each one is written in red marker on a separate flip chart page. As people name challenges, others might burst out with an idea for a solution or a comment - those also get written on the page with the challenge, in a different color. But the emphasis is on problems.

Now there's a break.

All the flipcharts from all the groups get put up on the wall. People wander around, writing comments (including, but not limited to, solutions) on the flip charts. This is very free form. People can also create new challenge pages (one problem/challenge per page).

At some point, people (either individually or in pairs, but no more) grab a flip chart page if that's a problem/solution that excites them.

People write a pattern draft using the notes on the page they chose. It's best if they use a template. That way, they won't inadvertently leave out things like forces or context.

These drafts may be ready to be workshopped (in the way that we'll do the previous day). If not, people read the draft of their pattern to the assembled group, and other people briefly make comments. (It's good if the patterns can be photocopied before the reading.)

If there's time, the patterns can then be revised and more can be workshopped the next day.

This is a lot to accomplish in the 3-4 hours we allotted to pattern writing on Day 2. We have flexibility, though.

Another possible next step is to look for gaps in the language.

1. Do a brainstorming-style session to come up with categories for the patterns. Use a different color index card for each pattern category. Write patterns on the cards, one pattern per card.
2. Run scenarios (for example, design scenarios) using the patterns. As patterns are used, pull out the cards and connect them with string. Look for gaps. When a gap is found, record the name and a short description of a pattern that will fill the gap. It can later be written and added to the language.

Steve Berczuk

Steve wants to create a pattern language, so these may be more appropriate on day 3. Here's an approach:

1. Come up with short names for patterns, emphasizing "noun things" (e.g., "Window Place", "Light on Both Sides"). Write the names on index cards.
2. Group cards according to categories that emerge (e.g., architecture patterns, etc.)
3. Try to create a linear-ish top-down structure in the cards (as in A Pattern Language).
4. Look for connections between groups of cards (these are like the Alexandrian context sections).
5. Now look for missing pieces. Also look for reasons to throw cards out.

Now pick a couple of cards and flesh them out. Writing a pattern with the idea of fitting into a pattern language leads to a different pattern.

Avoid sprawl. Pick a constrained domain, or pick a small language and have people flesh it out.

Brian Foote

Brian believes in giving people an example and telling them, "Write something like this". Get something written the first day, then workshop it, then iterate. The second day accomplishes more. People work individually or in pairs.

Robert Hanmer

In a group of 5-12 (where 12 is on the high side), brainstorm about things that people do (e.g., solutions or nuggets of solutions). The goal is to list those things that novices might not automatically do, then find a way to explain them.

In addition to solutions, also list parts of the common vocabulary that is used when testers talk to each other: "You know, we should put wrappers around controls" or "we need a dashboard for the project room". These might be pattern names.

Take a break. (Note: throughout the following, it's always OK to add new things to the list.)

Do people understand what all the solutions and names mean? If not, briefly explain them.

At this point, depending on the crowd, it may be useful to make connections between the patterns ("if you do X, you probably will then want to think about Y"). Metaphor: here, you're connecting the dots.

Pick one pattern, probably the most commonly known or least contentious or the one that resonates most with the crowd. As a group, flesh it out. If you're starting with a name, what's the solution that's named? What are the forces at play in this context? What's the problem? (Forces should come before problem statement.) [Possible danger at this point: the pattern may seem too trivial. That's OK, so long as it wouldn't seem trivial to a novice in the field. For an expert, a good pattern should evoke a "Ah, that's why we do it that way" reaction.]

He recommends writing in Coplien form (which has specific sections for Problem, Forces, etc.) because it ensures that essential elements don't get left out. Later, he recommends converting into the Alexander format.

Now is a good time to reflect upon what you just did.

Now look for relations among patterns. Don't worry now about fleshing out particular patterns; flesh out the structure of a collection of patterns. Find ones that are missing. Show which ones go together. Connect the dots.

Workshop a version the next morning.

Iterate.

The most likely thing to go wrong is for people to invent solutions for problems they haven't solved, rather than describe solutions for problems they have solved. This is a reason for starting out with solutions in the brainstorming, rather than problems.

[an error occurred while processing this directive][an error occurred while processing this directive]