Affinity Diagramming With Multi-voting

Affinity Diagramming With Multi-voting

Affinity diagramming is one of my favorite quality techniques. The technique is useful in any situation that requires generating ideas or getting a team talking. After generating ideas the technique provides a platform for organizing those ideas. I have used the technique for any scenario in which brainstorming would be appropriate, such as requirements definition, solution generation, process improvement and retrospectives. Affinity diagramming is generally a group technique with a facilitator acting as an anchor.

You need:

  1. Sticky notes (square, 3 inches by 3 inches)
  2. Flat surface (wall or other flat surface)
  3. White board/Flip Chart and dry erase markers

The process:

  1. The first step in the affinity diagramming process is for the facilitator to generate a set of framing questions that will be used to elicit ideas, comments or statements about area being studied. For example
  2. The second step is brainstorming. The facilitator will use the framing questions to get the team to generate ideas, comments or statements. As the team members think of a comment based on the framing question, they write the idea on a sticky note, call out what was written and then hold it up for the facilitator to post on the wall or other flat surfaces. Lettering on the sticky note should be able to be read from across the room. The brainstorming process goes on until the team has exhausted the subject or the time box is used up. Small sticky notes are used to ensure that each note contains a single, short idea.   Typically a team of 5 – 9 can generate 50 to 100 sticky notes during a 30 minute brainstorming session. The facilitator should ensure everyone participates. The facilitator should shift the seed questions as idea generation slows down.
  3. After the competing of the brainstorming phase, the team goes to the wall (or other surface) and re-arranges the sticky notes without conversation. The goal is to discover the relationships in the data. Time box the mute mapping exercise to about 1/3rd of the time of the brainstorming phase. A team is done re-grouping the data when everyone sits down or one item begins shifting spots without other changes. The facilitator should ensure everyone participates without talking. While atypical, not all items will be able to be grouped. Occasionally one or a few ideas will be outliers.
  4. After completing the mute mapping, the facilitator should walk the team through the groups of ideas that have been created. The facilitator begins listing off the entries in the group and then asking the team to name the group. The goal of this phase in the technique is to validate that each idea belongs in the group. The team is free to move notes to the groups if they fit better somewhere else.

Affinity diagramming with mute mapping is a tool to generate and sort a large number of ideas, comments or concepts into a more manageable order. Affinity diagramming is good for decision making, generating an initial product backlog, generating personas for user stories and retrospectives. Affinity diagramming with mute mapping might not be as versatile as duct tape, BUT it is close!

Crowds are susceptible to groupthink.

Crowds are susceptible to groupthink.

Brainstorming has been a staple in the business world since its creation in the mid-1940s.  Other forces have combined to reinforce the technique such as the mania over crowd sourcing and consensus management styles.  The problem is that the data shows that the technique is not as effective as we all believe, and in some cases can actually be unproductive – such as when groupthink occurs.  There are better ways to generate innovative ideas.

Brainstorming is a process that through free association generates ideas to find a solution or conclusion for a specific problem.  There are a core set of tenants that define brainstorming.  It is generally a group activity that includes a focus on generating as many ideas as possible (quantity), which includes welcoming unusual ideas, combining and improving ideas and the avoidance of criticism.  Great stuff!   However, research[1] has recently questioned whether the process is as effective and efficient as the popularity of the method would suggest.  The research suggests that the reliance on groups and a lack of debate and criticism causes the technique to be less effective at generating creative ideas than other techniques.

Why do you and I care about this topic?  Developing new ideas and innovative solutions is an integral part of software development, enhancement and maintenance.  Using the most effective techniques, or at least knowing what the most effective techniques, is of more just of academic interest.

Groupthink happens when the desire for harmony in a group overrides a realistic appraisal of alternatives.  The after effects of a groupthink gone wrong might include the passive aggressive comment: “I knew this wouldn’t work but did not say anything.”  “Idea gravity wells” and the forbearance of criticism help to create the problem.

Brainstorming and other group techniques for generating ideas leverage the diversity of thought a well-defined group[2] can create. Groups that allow a single powerful individual to dominate can create an idea gravity well that curtails innovation or green-field thinking as new ideas can’t escape the status quo. The problem is that conclusions that have been influenced by groupthink may not hold up in the bright light of the marketplace.

The second criticism is the lack of immediate feedback.  Forbearing debating and criticizing ideas, like a critique in art school, avoids exploring the depths of an idea and deciding quickly what is relevant.  Critiquing ideas makes sure the good parts are honed and built upon and the bad stuff either refined or sloughed off.   Debate, discussion and criticism create a platform to provide immediate feedback, allowing a group to reshape the idea being examined rather than building on a poor base.

I have been experimenting with and honing a process that attacks two of the major criticisms of brainstorming.  The process begins by making sure you have the right team (see the well-formed team footnote).  I strongly suggest using video if you have remote participants.  Make sure you have someone that will act as the scribe and someone that will also act as the moderator for the session.  Second, provide the “team” with the topic being explored and all background information before the planned session.   Each team member is responsible for reviewing the data and developing a list of their best ideas . . . individually.  Generating the initial set of ideas helps to avoid the possibility of groupthink or idea gravity well occurring directly out of the box.  Note: The list of ideas from each person is the price of admission; lack of preparation should bar a potential participant from the session.

The ideation session begins with a round-robin presentation of ideas from each participant with discussion, debate, criticism and refinement (no fisticuffs or off-topic criticisms).  The round-robin presentation generally continues until everyone has put at least one idea on the table or until the initial set of ideas are used up.  I allow and encourage participants to switch to more of free-for-all for laying out and discussing ideas as soon as everyone has completed laying out at least one idea.  Get one idea on the table from each person makes sure all of the participants understand that they have permission to participate.

I allow the process to continue until team members’ lose the will to live, run out of ideas or reach a consensus on an idea or idea set.  I believe that the facilitator or moderator should push a team at least slightly past what is comfortable in order to generate potentially extraordinary results.  Pushing past what is comfortable is one of the reasons I ask interviewees on my podcast for two ideas to solve the problem presented at the end of the interview rather than just one, which would be far more comfortable (note off the record: many interviewees have indicated that one response to the “two things” question would be far easier).

My wife suggests that after the session is complete, give everyone twenty four hours to chew on the topic and then reconvene to make sure that reflection has not provided tweaks to make the solution or solution set better.  Remember that not everyone thinks at the same rate as everyone else.

Why do we think brainstorming works?  We all have experience with the process.  It is comfortable, it is safe and in many cases it generates good ideas . . . just not the best ideas possible.  To brainstorm or not to brainstorm, that is the question, perhaps not exactly Shakespeare, but relevant nevertheless.  As we gain a better understanding of what works and why, when it comes to generating innovative ideas isn’t it time to put aside preconceived notions based on hearsay?  The data from academia suggests that what we know is based on just that — hearsay.  Don’t let data get in the way, you might say; we believe what we believe.  This week I announced to a group that brainstorming was not as effective as other techniques in terms of generating innovative ideas.  You would have thought that I had insulted their children.  Everyone has a story about successes using brainstorming.  Those successes may well have helped us get out of tight situations, but because of those successes it is hard to acknowledge that there are better ways to generate solutions and new ideas.  This is true whether we are discussing idea generation, software development or Marigolds and Moonflowers (something absolutely unrelated). Brainstorming may still have a place at the innovation table, but it should no longer sit at the head of the table.  There are better ways to generate creative solutions and now is not the time to leave creative ideas on the table . . . maybe it is never time to leave creative ideas on the table!

[2] Well-formed means that only the minimum number of people should participate and that those that participate include a range of experience and backgrounds.

Crowd sourcing is a key retrospective technique.

Crowd sourcing is a key retrospective technique.

Even though there are many different techniques for executing retrospectives, many teams find one or two techniques they like, and then they ride that horse until it collapses.  As we noted in Retrospectives: Obstacles, every Scrum Master and team should have a broad array of retrospective techniques, such as the sailboat technique, the Four L’s or the timeline.  This provides at least two benefits. First, knowing many techniques means that you can match the technique to the particular teams. For example, many techniques use physical sticky notes, which are difficult for distributed teams. So, the Scrum Master needs to know that you can substitute an on-line mind mapping tool for sticky notes.  Second, having a wide range of techniques (and using them) is a formula for beating technique fatigue and the resulting obstacle.

List generation techniques are the most popular class of retrospective techniques.  The list generation techniques are popular because they take very little set-up, are easy to explain, easy to facilitate and get results. Listing techniques build on well understood brainstorming techniques to ensure the whole team has a voice.  Before, we described how to do a retrospective using a simple listing and grouping technique, also called Affinity Diagraming.

Another technique in the listing category would be the Sailboat technique.  This method uses a nautical metaphor.  The boat moves through the water toward a goal (the team delivering functionality), the wind pushes the boat forward.  As the boat moves through the water, it encounters resistance which slows its progress. Examples of resistance might include conflicts for needed resources or conflicting organization goals.   Here is the process:

  1. Set-up: Start by drawing a picture of a sailboat in the water on your white board or flip chart. Explain to the team that some things push forward, like the wind, and some things slow your progress down, like an anchor.
  2. Idea Generation: Ask the team to identify what those items were.  List one item per sticky note, which are then placed on the boat.  As a facilitator, I will continue to tweak the seed questions I am using to keep the team thinking about the sprint from different angles.  You are done when the team is done.
  3. Insight Development: Have the team review the data and group ideas based on how they see the relationships between individual ideas. Techniques like Mute Mapping (grouping without talking) help to maximize team participation while minimizing the chance of a single person dominating.  Once THE grouping is done, I typically ask the team to name each group. This helps to cement the group’s understanding of the groupings of ideas that they have generated.
  4. Identify Improvement Objective: Select a group or specific idea to fix.  There are a number of techniques to select the improvement objective. Discussion followed by group consensus is one method (I use this when it is apparent that the group is close to consensus).  Another method is to vote using dots or post-it flags. In this method give each member a fixed number of flags and then ask them to vote (they can use all votes on one item or spread them).  The item or group with highest number of votes gets fixed first.

Examples of other listing techniques include:

The Four Ls – Use four categories: liked, learned, lacked, and longed for to generate ideas. Write these titles on four flip charts and place around the room.  Have each person silently generate ideas based on those categories.  When the team is done (i.e. everyone stops writing) have the team place their ideas (written on sticky notes) on the appropriate flip chart. Once the team has come up with their lists, identify the improvement objective, usually from the lacked or longed for category.

What Went . . . – Use four flip charts, put one of the following titles on each flip chart: what went well, what did not go well and what should we do more of and what should we do less of.  Brainstorm ideas to put on each flip chart.  Put one idea or statement on each sticky.  Depending on the group, this method can be done non-verbally (everyone puts their ideas on a set of stickies like the Four L’s) or have the team write ideas down and then shout them out (more akin to classic brainstorming). Insight development and identifying the improvement objective would follow a similar path to what was described above.

There are many other listing techniques each using a different set of seed questions (e.g. What worked well? or What would you like to do more of?) or different metaphors (e.g. sailboat, motorboats or trees). The questions or metaphors exist to help the team focus their discussion.  The metaphor or seed questions that are used need to make sense to the team’s culture, and also solicit areas that they are concerned about or can be improved. The Scrum Master or facilitator needs to use their observations about the team to select the retrospective technique that will provide the greatest benefit . I have seen teams of engineers that did not like using techniques that used metaphors (like the sailboat), while a UI team I worked with loved techniques that used metaphors. All of these techniques can work selecting which you will use is matter of team culture.

We will discuss techniques that are not list based here.

Related Entries:

Retrospectives: A Basic Process Overview

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Obstacles

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event

Don't gamble on team issues resolving themselves.

Don’t gamble on team issues resolving themselves.

Retrospectives are part of most methodologies, even though there are many different terms. For instance, most waterfall frameworks call them post implementation reviews or postmortems. And each methodology focuses on different nuances. Agile, as a macro set of frameworks, has more aggressively embraced retrospectives than waterfall or iterative frameworks.  Retrospectives in Agile reflect the adoption of the principle of kaizen (Japanese for improvement, often interpreted as continuous improvement). They should be focused on discovering what will make the team or organization deliver more value. While many retrospective techniques posit the questions “what worked well” and “what did not work,” the real reason to do any retrospective is to identify, agree on and plan for what can be done better. The exact process any team uses is a reflection of the technique the team wants to use, what works in the organization and the specific team situation. For example, the timing of retrospectives varies significantly depending on the framework and the organizational culture.  Most waterfall projects do a retrospective at the end of the project (or release), while Agile projects typically do retrospectives at the end of every sprint, at each release, at the end of the project and occasionally on an as needed basis.  In Agile, retrospectives occur when change can actually be applied to the project to impact the current delivery.

This is the basic process for a typical end-of-sprint retrospective:

  1. Set Up:  First, create a safe atmosphere (I review Norm Kerth’s Prime Directive with the team). Then ground the team by focusing on the current sprint’s results (for example review the Burn-down Chart or have the team develop an annotated sprint timeline). Time box this part of the retrospective to no more than 20 minutes for a two week sprint.
  2. Idea Generation: Encourage the team to dig in and capture the details.  For retrospectives focused on process or flow, I often use sticky notes to brainstorm, followed by mute mapping to group (affinity diagraming). For team or personnel issues, I use storytelling. For example, have subsets of the team describe a fictional scenario based on real life problems and how they would solve the problem. I have also used direct discussion. This step should be time boxed to 30 minutes for a two week sprint.
  3. Insight Development:  Once the idea generation step is completed, the team reviews the data and comes to a consensus about what it means. One method of analysis is to look for patterns and to determine if there are trends in this stage.  The goal is to recognize if there is a problem so you can start to resolve it.
  4. Identify Improvement Objective:  In many cases a team might have identified a number of ideas for improving their productivity. Focus on the top one or two big wins.  The rational for not fixing everything is first that the time need to fix the problem will come from the team’s capacity to deliver business value (there is only so much capacity that the team has at its disposal).  Secondly, if the remaining issues are really problems after the one or two most important have been dealt with then the team can decide to address them during the next iteration. FYI, this continuous incremental process improvement is one reason team productivity, aka velocity, typically increases from iteration to iteration.  After the team selects the issue (or issues) to be tackled, have them add it to the next sprint backlog so that they get addressed.  This step should be time boxed to 30 minutes for a two week sprint.
  5. Wrap-up: Spend 5 – 10 minutes reviewing the session so that the next retrospective will be even more effective.

Retrospectives are a tool that the team uses to identify what they can do better.  The basic process – making people feel safe then generating ideas and solutions so the team can decide on what they think will make the most significant improvement – puts the team in charge of how they work.  When teams are responsible for their own work, they will be more commitment to delivering what they promise. The retrospective process is focused on increasing the team’s capacity, rather than trying to generate lessons learned for the next project.

Related Entries

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Obstacles

Retrospectives: Listing Techniques

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event

Every task requires the right tools.

Every task requires the right tools.

Team-based decision-making requires mechanisms for creating consensus among team members. There are certain prerequisites teams must satisfy in order to make a decision. The prerequisites are a decision to be made, trust, knowledge and the tools to make a decisions. In many instances, we assume that team members have the required tools and techniques in their arsenal. Unless team members have been trained in tools to generate consensus, this is rarely the case. Here are three decision-making techniques that each team should have: voting, Fist to Five and the nominal group technique. Each technique is more complex than the next and is representative of many other similar techniques.

Voting is a decision-making technique that almost everyone understands. The simplicity of the process is a major positive of this technique. The downside to voting is that someone (or some group of someones) will lose. The win/lose dynamic can create a divide within the team which can pull it apart over time or generate passive aggressive behavior.

Fist to Five is a tool that combines consensus building and voting. The technique has been attributed to numerous people or organizations ranging from Jim Highsmith to the American Youth Foundation. Fist to Five introduces an element of the common “yes”/”no” vote. Each participant responds to a proposed solutions with a fist or up to five fingers. A fist is designated as a “no” (and I will try to block the decision). The number of fingers is a “yes,” with an indication of how good a “yes” is, it usually ranging from one meaning the voters still has some issues to five meaning the voter will man the barricades to fight for the decision. Fist to Five provides a way to check the “sense of the group,” and the quality of the consensus on a scale.

Consensus decision-making requires involvement and commitment. Many group-oriented techniques have been developed to generate involvement, such as brainstorming. The goal of brainstorming is to give team members an opportunity to engage. The nominal group technique (NGT), uses a more structured format to obtain multiple inputs from a team on a particular problem or issue. This mechanism is often useful to help new teams as they build relationships and for distributed teams where formality can be used to combat distance.

NGT is a structured group discussion/voting method. The format prevents the domination by a single person or subject matter expert. The output of the process is a set of prioritized ideas, solutions or recommendations. The steps for a sprint team are:

  1. State an open-ended question (“How are we going to solve a business problem?”).
  2. Each team member will spend 5 – 10 minutes in silence individually brainstorming all the possible ideas. Write each idea on sticky note (if in person) or write the ideas in an electronic note (if the team is distributed).
  3. Share the ideas in a round robin manner with someone acting as a recorder adding each idea to a flip chart or shareable mind map. (Round robin is one response per person rotating until all ideas are recorded.). Use the classic brainstorming rules of allowing no criticism and allowing requests for clarification.
  4. Have each person evaluate the ideas and then anonymously vote for the best ones (I typically suggest voting for the top five, five being best and one being the lowest). The idea with the most votes wins.

Variant: discuss the top vote getters and then revote.

There are a myriad of group decision-making techniques. They vary in complexity and each try to address issues that a team might have when creating a decision. However, none of these techniques have ANY value if the team is not aware of the technique or cannot execute the technique. Teams can struggle creating a consensus, become passionately split on an idea or simply struggle to understand the options that are appropriate. Each team needs a pallet of decision making tools available (or a coach with those techniques), or they risk failing to make good decisions or to make decisions in a timely manner.

Memorial Day

On Memorial Day 2013, Daily Process Thoughts and The Software Process and Measurement Cast wants to thank all of those in the United States Armed Services that have paid the ultimate price in service of their country.

For those not in the US, Memorial Day is a day dedicated to the remembrance of those that have fallen while serving in the United States Armed Services (Wikipedia has a good history).  It also marks the beginning of summer, and if you believe the Connecticut Post, the beginning of the barbecue season. Conflating all of these ideas together is at best confusing and maybe a bit demeaning to the tribute the day is supposed to reflect.

Definitions matter! A common set of definitions facilitates clarity of thought and communication. As we discussed in earlier Daily Process Thoughts, commitment is saying what we will do then doing what we say. In order to make this type of commitment work we need a common understanding of what we are actually trying to do.  A common set of definitions a required first step.

What exactly do I mean when I use the terms Agile, framework or effective? Lack of common definitions may mean that we are speaking different languages. If you don’t think that can be a problem just try order noodles off the beaten track Beijing if you only speak English. One of the team building steps I commonly suggest is to create a common set of definitions early in a project. This can be done during project chartering using brainstorming to identify potential stumbling blocks and then developing a common set of definitions, a team glossary and a common vehicle for communication.


Programming Notes:

Daily Process Thoughts will begin an arc focused on definitions.  We will tackle words like effectiveness, efficiency, framework . . . maybe even Agile and Waterfall.  Are there other terms you would like to put on the list?