Motley says: "Affinity exercises? How do I work that sideways "8" into brainstorming?"



Motley:  Affinity exercises? How do I work that sideways "8" into design brainstorming?


Maven: Use affinity exercises for generating lots of ideas and prioritizing them. Define the topic, generate ideas, categorize, discuss, prioritize using dot voting, add up the votes, and create the summary.



[Context: After the talk on team checklists, Motley was motivated to create a team code review checklist, but had some difficulty]


Motley: After our recent discussion on checklists, I was inspired to create a team checklist for use in code reviews. A few common problems appear fairly regularly, and I want to ensure everyone looks for them during a code review.


Maven: Sweet! Glad to see you are implementing some quality practices. Checklists provide a great reminder of frequent errors, as we discussed.


Motley: I thought I would get everyone together to determine what issues to look for in code as a team. We ended up focusing on one or two things and had in-depth discussions. By the end of the hour-long meeting, we didn't have much that was useful. I then had a chat with Mort and we came up with too many ideas - the opposite problem. We didn't know how to narrow them down. In the end we had nothing. Pretty much a waste of my time and the team's time.


Maven: Ah, yes - the unstructured brainstorm session. Brainstorming with a team is actually a very difficult exercise if you don't set some ground rules and put some structure in place. Have you ever tried an affinity exercise?


Motley: Affinity exercises? How do I work that sideways "8" into brainstorming?


Maven: Affinity. Not "Infinity".


Motley: Oh.


Maven: An affinity exercise is a brainstorming technique for many types of problems. By following a very simple structure, you can generate a lot of ideas in a short amount of time and come out of the meeting with a list of the most important ideas to the team.


Motley: As long as I keep all my limbs and I don't end up taking anyone else's, I'm game to hear more. Doesn't "affinity" have something to do with attraction? Is this exercise appropriate for a work environment???


Maven: Sometime I'd like to get a look into the depths of your conscious as I am sure there are some scary things in there.


Motley: Get on with it.


Maven: Ok. The affinity comes from the fact that you are going to generate a lot of ideas and examine the relationship between those ideas. First you need to stock up on Post-It notes, find a room for the team, invite a few people, and schedule an hour for the exercise.


Motley: What are the Post-It notes for?


Maven: You will soon see.


Motley: Hmmm… I think I'll have to bring back a few pads that I, um, borrowed for home use because our supply cabinet is running low. How does the exercise work?


Maven: The first part of the exercise is to define the topic to be brainstormed. Provide an overview to the team on the problem for which ideas will be generated.


Motley: Ok - we are generating a checklist for reviewing production-quality code. Next?


Maven: Great. Individuals generate as many ideas as possible. An easy way to do this is by presenting each person in the room with a stack of Post-It notes to be used for writing down one idea per note. Give the team about 15 minutes of silent time to write down as many ideas as possible. Write down an idea, rip off the Post-It note and put it beside you, then repeat. There are no wrong answers, we don't worry about duplicates between individuals,  and there is no discussion at this point. Anything goes.


Motley: One idea per Post-It note. Everyone is quiet, heads-down and writing for about 15 minutes, or presumably until they run out of ideas.


Maven: Exactly. Once all of the ideas have been exhausted or the time limit exceeded, everyone posts their ideas on a flat surface (wall, whiteboard, paper, etc.). If two people come up with the same idea, they overlap the Post-It notes. The overlap provides a real-time filtering of duplicates. I recommend using a Whiteboard for this if possible so that you can draw on the surface.


Motley: What if the ideas are similar but not identical?


Maven: The next step after everyone has their Post-It notes on the wall is to find the relationships between ideas and categorize the ideas together. Create logical groups based on the types of ideas that were generated. For example, if you are creating a code review checklist, there may be several items related to security like checking for correct buffer usage. Group those items together, draw a box around them, and label the category/theme. The category helps provide context around the ideas, and may even be a checklist item in itself if the ideas within the category are too specific or really represent one central idea.


Next, you want to discuss the ideas to ensure everyone understands the complete set of notes. Because the Post-It notes typically do not contain much text, some explanation is required from the authors. The explanation may also lead to a few more ideas, so as people in the group have them, they can post a few more on the board.


Motley: What about the dumb ideas - presumably we don't want to waste time discussing those?


Maven: Encourage people to be as creative as possible and think outside the proverbial box. There are no "dumb" ideas. If, in your head, you feel an idea is not feasible, keep it to yourself. It will come out later in the exercise.


Motley: We have the ideas generated and displayed, and we have an understanding of what they are. This still doesn't solve one of our big problems - too many ideas posted and either no idea how to prioritize them or some disagreements on how to do so. This technique looks great for generating the ideas, but prioritization is still an issue.


Maven: I'm not done yet! Of course, the members of the team may have differing views on which are the highest priority ideas. We discussed previously that checklists should be kept to around a page in length to be useful. Chances are good that after an exercise like this you have multiple pages worth of ideas. The group must narrow them down.


Motley: I'm waiting…


Maven: Here is a good technique: make sure everyone has a pen or marker. Each person gets seven votes to use how he or she pleases. The votes can be distributed across the ideas in any way. For example, perhaps Marcy really wants to see two of the items on the team checklist - she can put 4 votes on one idea and 3 votes on another. If Mark sees 7 ideas that he feels should be on the checklist, he can put 1 vote on each of 7 ideas. Voting is typically done by placing one dot per vote directly on the Post-It notes. Not surprisingly, we call this "dot voting."


Motley: Simple but effective. After everyone has had all their votes, we tally up the total number of votes for each of the items and take, say, the top 10 for the checklist.


Maven: You got it. Those top 10 will be the ideas the team is most concerned about for code reviews. Notice, too, that the ideas that are not feasible get left out, but no one feels bad because someone insulted their idea. The exercise allows us to wade through a large number of ideas, prioritize them appropriately, and produce a result that the team is happy with.


Motley: Awesome - we're done!


Maven: Not quite. Someone then needs to take action and write down the checklist in whatever form your team uses (e.g. wiki, InfoPath form, etc.), ensuring it is made available to everyone in a place they have access to. The exercise was useless unless we capture the results and the checklists is used by the team.


Motley: That goes without saying. I could see us using this technique for lots of different kinds of brainstorming activities, from where to go for dinner to what weekly practical joke to play on you.


Maven: Please, no more practical jokes. I'm still trying to get that tree sap off my jeans.



Maven's Pointer:  There is no magic to using 7 votes for dot voting. Using an odd number helps people prioritize more than using an even  number that they can split evenly. For larger groups of people, you may want fewer dots, like 5 or 3. For smaller groups of people, stick with 7 or 9 or larger as there will be fewer dots to go around due to less people in the exercise. The risk with fewer people, however, is that one person can manipulate the results a little more by putting the majority of their dots on one item.


Maven's Double Pointer Indirection:  When the exercise is complete, take a digital photo of the whiteboard containing the Post-It notes in case you want to review the session later or see what other ideas were generated should some items start disappearing off the checklist as they are no longer frequent errors.


Maven's Triple Pointer Indirection:  Remember the discussions on Human Performance Technology. You can use the Six Boxes to guide people's thinking a little bit more in various areas that may be relevant to your problem, particularly if the number of ideas being generated by the team is low.


Maven's Resources: