TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Collaborative Card Play


A StickyMinds.com Original
Article Picture
Collaborative Card Play

By Jeff Patton

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Ever find yourself spinning in a conversation where the discussion of ideas gets stuck in a circuitous route? In the world of software development, where the need to effectively communicate elaborate and complex ideas is most important, such conversations end up being counter-productive. In this week's column, Jeff Patton shares a technique that keeps such conversations on a straight and productive path. Find out how he channels different ideas and categorizes them—all within one very fun and productive meeting.


HP
Some people talk with their hands. I talk with cards. Here's why.

Have you had a conversation where a lot of ideas are discussed, yet the conversation just seems to spin around? A half hour into the conversation déjà vu hits. You ponder, "Didn't we discuss this already?"

Have you worked with a group of people that simply need to prioritize a list, but after what seems like hours of discussion the group makes no headway?

There's a simple approach to these situations that I've been using for years. Other people are often surprised it works well for them. The technique is simple:
  1. When talking to people, write ideas down on index cards.
  2. Place the cards on a table in front of the group.
  3. Watch what happens.
Pretend for a minute we're in the early stages of a software project. As part of getting started the team might build a risk list, and then draft a plan to mitigate the most critical risks. Usually these actions take place during simple discussions, where someone takes notes or writes things on a whiteboard or flipchart paper, so consider using cards to see how that works.

Get Some Ideas on the Table
Prepare for the discussion by getting several hundred index cards and a few markers. Then, get your team together to talk about the project risks. Sit around a table—any conference table will do, just make sure everyone is visible. Place the stacks of cards and pens in the middle of the table.

A simple affinity diagram built on a restaurant tabletop after dinner.

Kick off by letting everyone know that you're here to build a risk list for the project and that you're taking notes on cards and will transcribe them into a document later. Then, get everyone's ideas about project risks. This can be done one of two ways:
  1. Talk about risks. As people talk, write down risks on the index cards, one risk per card. Use the markers so the message may be read easily by everyone around the table. If you get behind, ask someone to help you. Place the cards with risks written on them in the middle of the table.
  2. Silently brainstorm. Ask everyone to grab a few cards and a marker. Then ask your group, WWhat do you believe are risks that could adversely affect the delivery of this project?" Tell them to take a few moments to silently write down the answers on the index cards—one risk per card—and toss the cards in the middle of the table. Let your team know that each risk will be discussed when they're done.
When everyone's done, arrange the pile of index cards in the middle of the table.

Find Similarities by Clustering
You've got a pile of ideas. Now what? Some of the ideas likely are similar to each other, just worded differently. Some of the ideas may be related in some way. We can learn more by clustering the ideas based on affinity.

Ask the group to arrange the cards in a sensible way. Ideas that appear to be the same or closely related should be placed together or near each other; ideas that are not related or more distantly related should be farther apart. Afterwards, you should have distinct clusters of cards arranged on the table.



During this activity, people should get up and move around. They'll become more animated. Conversations about the risks will involve a lot of pointing and the use of the pronouns such as "this" and "that." Being able to gesture to a card, refer to the risk as "this," and not say all the words on the card facilitates communication and saves a bit of time in the conversation.

Distill Your Ideas
Now that you've got clusters, let's summarize each pile in a useful way so we have fewer and sharper ideas to work with.

As a team, discuss each cluster. Write a single risk down that summarizes or distills all the ideas in that cluster of cards, giving you a single distilling card per cluster. When writing this card, use a different color card if available; otherwise, underline the text written on the card. Place the distiller card on top of its respective cluster.

You may have started with a large number of cards (forty, fifty, or more is common for this type of exercise). With luck, distillation will bring the number of cards down to a fraction of its size (twelve or fifteen).

Distillation should incorporate everyone's ideas successfully. At this point, everyone should feel a sense of accomplishment. You also might notice that no single person seems to "own" this list—the group members own it together.

Prioritize
All the risks on the cards aren't equally important; some are more worrisome than others. Prioritize each risk by asking each person to vote for the risks he believes are the biggest threats to the project. Give everyone a small number of votes. Calculate the number of votes given to each person by taking the number of distilled risks, divide by four, and then round up. For example, fourteen risks divided by four equals 3.5, which rounds up to four votes. Ask people to mark their votes directly on the distilled risk cards.

A typical affinity diagram built on a meeting room conference table.


Two or three distiller cards might get a large number of votes, and others might get only a few votes. Some of the cards might get no votes at all. Now you know what risks need the most discussion and which ones you don’t have to waste much time on.

Repeat
Once the most worrisome risks are identified, it's time to talk about a mitigation plan that specifies what actions to take to reduce these risks. Starting with the most worrisome risk—the one with the most votes—get some ideas for actions onto the table. With those actions, repeate the clustering, distilling, and prioritizing processes.

By now your group should be impressed with how easy, clear, and fun this is. Normally risk identification meetings are long and annoying.

You've Built an Affinity Diagram, But Don't Stop There
You've just used the index cards to build a simple affinity diagram. It's a technique commonly used to distill ideas. Using cards and collaboration makes the process fast, effective, and fun.

But don't stop there.

Bring cards and pens to every meeting. As you're talking, write ideas—one per card—and place them out where others can see them. You'll find you can easily arrange cards into timeline-like sequences, build simple hierarchies of ideas that contain other ideas, or prioritize lists quickly by voting or rearranging lists on a tabletop. You'll find that all this happens quite naturally.

Collaboration techniques like simple card modeling help speed up communication and make it more effective. In software development, where ideas become complex and making sure everyone understands what's on the table is critical, approaches like card modeling become critical as well.

A massive affinity diagram built from stickies by a collaborative group of over 100.


For more information on collaboration skills see Jean Tabaka's Collaboration Explained.


About the Author
Jeff Patton leads teams of Agile developers to build the best software possible. He proudly works at ThoughtWorks. Jeff's series of columns on software design and pre-design tips appears regularly on StickyMinds.com. Jeff's blog, presentations, and other articles can be found at www.agileproductdesign.com.

Back to Top
 

StickyMinds.com Weekly Column From 3/12/2007 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Ellen Gottesdiener 3/15/2007

Nice piece, Jeff! and great suggestions Sidney.

The term JAD (an IBM trademark) is now like "kleenex" -- a generic term for a faciltiated workshop. Classic JAD smacks of CUI (character user interfaces), DFDs and other 'older' methods and thus is less referred to. Rather than cards, classic JAD relied on magnets on whiteboards, btw.

The techniques that Jean, Scott, and myself have written about make strong use of low-fidelity tools and techniques such as cards, working on wall, and just-enough and just-in-time modeling. (My first book, Requirements by Collaboration [http://www.ebgconsulting.com/Pubs/reqtcoll.php] and...Read On

Author's Response:
3/15/2007    
Ack - how could I mention Jean's book and not yours! Jean's is new and shiny on my desk. Your's is dustier and dog-eared on my shelf. An important take-away for me is that levering collaboration has been important in software development for a very long time. However, it's not as simple as putting a bunch of folks in a room. There are some skills that make it more effective. Your book, Ellen, Jean Tabeka's, Scott Ambler's and likely lots more give some guidance on how to pick up those techniques.

 
 
Comment:    
by Ellen Gottesdiener 3/15/2007

Nice piece, Jeff! and great suggestions Sidney.

The term JAD (an IBM trademark) is now like "kleenex" -- a generic term for a faciltiated workshop. Classic JAD smacks of CUI (character user interfaces), DFDs and other 'older' methods and thus is less referred to. Rather than cards, classic JAD relied on magnets on whiteboards, btw.

The techniques that Jean, Scott, and myself have written about make strong use of low-fidelity tools and techniques such as cards, working on wall, and just-enough and just-in-time modeling. (My first book, Requirements by Collaboration [http://www.ebgconsulting.com/Pubs/reqtcoll.php] and...Read On

 
 
Comment:    
by Sidney Snook 3/13/2007

What you have described contains some of the elements and intent of Joint Application Design/Development (JAD) sessions...a methodology I learned and practiced during my career for several projects large and small.

Focusing on basic successful meeting elements is a good idea no matter how the advise is packaged or named:
Use experienced and skilled facilitators
Get Executive Sponsor’s /management commitment and support
Get the right people to participate, predefine their roles and
responsibilities
Set clear defined, well understood and obtainable goals or objectives
Plan detailed...Read On

Author's Response:
3/13/2007    
I agree. A JAD style approach seems to be making a comeback - but oddly without being named JAD. Books like Jean's "Collaboration Explained" reinforce your message about well run meetings and good facilitation. Ambler's "Agile Modeling" approach reinforces the need for using lightweight models for understanding elements of software development. It makes me wonder if we've moved forward, or reinvented? ;-) I do find using card models that everyone in a group can interact with an advantage over working on a whiteboard. I wonder what would have been recommended best practice in a JAD approach?

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


ThoughtWorks

Rally Software




Agile Development Practices 

STARWEST