Multitasking game - Hands/Numbers/Song

Most of us find ourselves multitasking at some point and are possibly even proud of our multitasking skills. Here is one game that was created by Alan Cyment with collaboration from Tobias Mayer and introduced to me by Gerry Kirk and Yves Hanoulle at SDEC11 that allows you to simulate the costs of task switching. I've since used it elsewhere and the results were quite effective for shaking the multi-tasking misconceptions.

(Note: Alan added a comment to this blog and I've incorporated some of his new ideas and changes - thanks Alan!)

The Game

Materials needed

• 6-20 people (note - if you have more than this, just split into multiple groups. In theory you can handle as many people as you have space for)
• One facilitator
• One stop watch
• White board / Easel or equivalent to record a few scores.

Suggested questions to ask before the game

• Who values multitasking?
• How many projects are you working on right now?
• Can we juggle tasks well?
• Who is great at multitasking?

Practice / Warm-up

1. Have each person pair up and then line up in two lines facing each other like this:
A1 A2 A3 A4 A5 (A1 faces B1, A2 faces B2, etc)
B1 B2 B3 B4 B5
• If you have an uneven number, you can ask one person to be your time keeper. If you have some sceptics or others who don’t want to participate, you can ask them to be observers ;). However, you need at least 3 pairs and more is better.
2. Have each pair practice the Hands activity as below
3. Now switch pairs by having everyone in line A move one spot. A5 will have to move all the way to A1. Your line should now look like this:
  A5 A1 A2 A3 A4 (A5 is paired with B1, etc) 
  B1 B2 B3 B4 B5 
4. Have each new pair practice the Numbers activity below
5. Now switch pairs again by having everyone in line A move one spot. You should now look like this:
  A4 A5 A1 A2 A3
  B1 B2 B3 B4 B5 
6. Have each new pair practice the Song activity below

Performing the game

1. This game will be performed in two rounds
2. Round One:
• You as the project manager will tell the teams which activity (project) to work on.
• You will bark out instructions ("Shout-Driven Develolpment") and they are expected to switch tasks on your command. For each activity they need to switch to perform the activity with the pair they practiced that activity with. (This will involve a lot of movement.)
• When each pair resumes an activity that they have already started they must pick up where they previously left off.
• Your time keeper should record the time when the whole team (all pairs) have finished each activity.
• Keep asking the team to task switch every 2-10 seconds (be random!) until all pairs have completed the activities.
• Record the completed time for each activity.
3. Round Two:
• You as the project manager will tell them the priority of the activities (projects). You will ask them to complete Hands first, Numbers second, and Song third. You ask them to complete each activity (project) before starting the next.
• Your time keeper should record the time when the whole team (all pairs) have finished each activity.
• Record the completed time for each activity
4. Your results should look similar to the results in the image below. Note: we played this game twice after adding more people - the purple numbers are the results of the second game.

Additional Tips and or Alterations

Alan Cyment commented on this blog (see below) with some alterations and changes that he is using. Take a look at some of these additional tips and ideas:

• Have the group decide how to rotate partners instead of defining the rotation for them.
• Run the sequential round first and then the multitasking round.
• Have the group choose their own song instead of Happy Birthday.
• For larger groups, ask them to put their hands up when they complete each 'project'. This will help the time keeper to understand when each project is completed amidst the chaos.
• Instead of acting as the project manager, act as the product owner who represents three different customers/stakeholders.

Questions:

• What did you think of the game? 
• What are some conclusions you can draw about how you are currently working? 
• Notice that in the second attempt you completed all three tasks before you completed the first one in the multi-tasking round. What do you think about that? 
• For the two rounds, notice your time to market.
• How different was the quality of your product in round one and two?
• What did you notice about your stress level in round one and two?
• What does this game teach us about sustainable pace?
• Describe your discipline level in each round. How much did your team cheat or ignore the manager's orders?
• How does that affect how you will work? 
• What happens when you task switch? 
• What are the costs to juggling tasks? 
• How can we change the way we work to take advantage of this? 
• What are the barriers to making this happen? 
• How can you respond to someone who is asking you to switch to another task or to split yourself between two or more projects?

The Activities:

Hands:

• Clap your own hands / Clap your both of your partner’s hands 
• Clap your own hands / Clap your partner’s right hand 
• Clap your own hands / Clap your partner’s left hand 
• Clap your own hands / Clap your right hand to your left foot 
• Clap your own hands / Clap your left hand to your right foot 
• Repeat once

Numbers:

• First person holds up 1 finger / second person claps once 
• First person holds up 2 fingers / second person claps twice (up to five) 
• Then switch roles and repeat once

Song

Sing/say the Happy Birthday song alternating each word. One person says the first word, your partner says the second, you say the third, etc:

• Happy birthday to you 
• Happy birthday to you 
• Happy birthday dear <name> 
• Happy birthday to you 
• Repeat once

Additional Resources:

Stats

From QSM 1, Systems Thinking (Dorset House, 1992). Jerry Weinberg:

• # of tasks = 1 - Time spent on task = 100% 
• # of tasks = 2 - Time spent on task = 40% 
• # of tasks = 3 - Time spent on task = 20% 
• # of tasks = 4 - Time spent on task = 10% 
• # of tasks = 5 - Time spent on task = 5% 
• # of tasks = more than 5 - Time spent on task = random.

Links on Multi-tasking

• Emails ‘hurt IQ more than pot’ 
• Leanblog podcast featuring Dave Crenshaw - author of “The Myth of Multitasking” - http://www.leanblog.org/2010/10/podcast-100-dave-crenshaw-the-myth-of-multitasking/
• The Myth of Multiasking - by Christine Rosen
• A blog with some cited research and links to short videos
• Three Myths and Three Tips - article by Johanna Rothman
• Brain Research - The Myth of Multiasking - video.
• Why Limit Your WIP: A 10 part series - Jim Benson.

Links on combatting multi-tasking

• Questions to ask to find out the urgency and importance from JB Rainsberger:
• What’s the good business reason to do this? (One of my favourites) 
• Why should I do this specifically today? 
• What would be the consequence of not doing this?
• Article by Johanna Rothman on how to say no
• Some articles by Esther Derby on this topic: 
• Yes. No. Negotiate
• Breakthrough Thinking on Worker Productivity 
• 7 Things Highly Productive People Do

 Subscribe to Winnipeg Agilist by Email

Sea Star Wars: A lesson in organizational change

Sometimes in order to make a change happen, all you need to do is change the environment.

This summer I witnessed a great example of this in a small but fantastic aquarium in Ucluelet, BC. When you see a sea star in the ocean or at the aquarium, you rarely or if ever see them move. However, the staff at the aquarium instigated a sea star race by changing the environment. They put the feared Morning Sun Star in the same tank with other sea stars including the very large Sunflower Sea Star. Once the other sea stars detected the presence of the Morning Sun Star they all started to move away from it as fast as they could. The sudden reactions and speed of those sea stars was a sight to see – a turtle would have been proud!

If you have analysts, developers, testers and users who don’t communicate very well you can help encourage better communication by changing the environment. Create a co-located space and then have them all work in that space together. The environmental change forces them to acknowledge each other’s presence and begin working together. Instead of “Hey, there’s a dangerous Morning Sun Star in here and I have to run away before it eats me”, you should get reactions like “Hey – there’s a user in here, I guess I’ll show them the changes I’m making to this screen to get some feedback”.


Subscribe to Winnipeg Agilist by Email

SOPA Blackout

I couldn't find a SOPA gadget for blogger, so in solidarity with all the other blackouts today here is a link to an article on why SOPA should concern you:

http://blog.reddit.com/2012/01/technical-examination-of-sopa-and.html

Here is the conclusion of that article:

"In Conclusion

It is my strong belief that both PROTECT IP and SOPA:

1. Will not stop the piracy they are targeting
2. Contain language that is highly ambiguous and extremely broad making them ripe for abuse, and
3. Introduce regulation and enforce censorship on what should be a free and open internet."

Estimating tasks in hours is local optimization. Stop doing it!

This weekend I was listening to Eliyahu M. Goldratt's "Beyond the Goal" where he expands on the Theory of Constraints. In chapter three I listened to him explain how estimating in hours is in fact local optimization and therefore "idiotic". Here is a portion of that chapter loosely transcribed:

"The way to ensure that the project will finish on time is to ensure that every task will complete on time. This is the local optima policy that leads to a huge conflict. Placing a person on such a project jeopardizes the most important thing for them - their own image.

Suppose you are this person and you are asked how much time will this task take? You are extremely reluctant to give any number. And when you give that number the Project Manager will try to squeeze it. Why are you reluctant? Because you know that the number you give is an estimate but that it will be converted to a commitment - because the project needs to finish on time.

So what situation does this place you in? This common procedure of turning estimates into commitments puts you into a huge dilemna. Why? The objective of every person is to be regarded as a reliable person by your boss, by your peers, by people. But what is the meaning of being reliable? For example, if you give a commitment and you don't meet it - once is ok. But if you give a commitment and many times don't meet them do you expect to be regarded as reliable? Of course not. So one of the conditions of being a reliable person is to meet your commitments.

Also - if you are fighting for something (an estimate) and then it turns out that you have exaggerated by a mile? If it happens once, fine. If it happens frequently, then you will get the name of someone who exaggerates wildly - so kiss goodbye the image as someone who is reliable. In other words, another consideration for being a reliable person is to not be considered as someone who exaggerates. Now look what is happening when I come and ask you how long it will take to finish this task?

Now look - whatever you do, you are doomed. This is a huge personal conflict. How do we in reality deal with this conflict? Let's face it - this conflict is so important we must find a way to break it. We want to not only be reliable, but to be considered reliable. How do we do it? We cheat.

So we finish our estimates on the nose and sometimes a little more. They become self fulfilling prophecies. If there is a danger of finishing too quickly we add some more tests, do a more thorough job, we add another function in, we check things a little more thoroughly, and we finish on the nose. Do you see what's happening?

Due to the result that our local optimization turns any estimate into a commitment, we have developed the habit of giving estimates which includes in it the safety. If murphy (i.e. Murphy's Law) doesn't hit, we waste the time rather than giving it to the next link in the chain or project. If we do give it to the next link then we are declared as exaggerating and next time they won't give us the extra time. So look what a horrible situation this is. And this... is what kills the project. This is totally idiotic"

When you read this story the first time you will likely notice there are several examples in there of how not to run a project, of poor leadership, and his concluding statement is a little harsh. As many commenters have pointed out, this style of project management is not similar to how we typically run agile projects. However, at the core of the story is the desire of each person to be reliable by meeting hourly estimates whether they are created by the team, by yourself, or by someone else. When I first listened to this argument I was fascinated by that part of it. So, if that part of his argument is correct, then what alternatives do we have if we need to estimate? (This paragraph has been updated based on the comments - thank you)

If your project requires an estimate:

• Stop estimating tasks or user stories in hours - hopefully the argument above has already given you enough reason to at least consider this 'radical' change.
• Don't estimate user stories in hours or convert relative points to hours. OK - I do understand that it can be valuable to look historically at hours vs. points, but don't use this conversion for guessing how long a task or user story will take.
• There is some evidence that due to variability, counting the number of stories completed in an iteration is of equal value to counting the number of points completed in an iteration (velocity). This would help keep the focus off of hours per user story or task.
• Where possible, avoid asking how many hours are left for a task or user story. I understand why and how this information can be valuable, but understand the risk you take when you ask this question. 
• If possible, estimate at higher levels (epics) rather than lower levels (user story).
• Give broad project estimates with ranges like 1-2 months, 3-6 months, 1-2 years instead of doing detailed estimates. Most projects don't need a detailed estimate in order to determine if they should be completed or not. For many projects on our list we already have a good enough guess about their size to understand their value compared to the cost. (Unfortunately, as a consultant that usually doesn't include the projects I work on).
• This logic also suggests that relative estimating might be dangerous. I still have to think about that one as there are significant benefits to exercises like planning poker even if estimates are not created as output.

If your project does not require an estimate:

• Do a little song and dance!  

In either case, continue to break down your project into smaller projects and small deliverable pieces of value and working code. Build the high priority pieces first in an iterative  fashion. Make a decision about whether the project is done after each completed story or each iteration to avoid the problem described above - the temptation to finish on your estimated completion date. Continue measuring your progress using completed stories but consider using cycle time (average time to completion for all stories) vs. velocity (average number of points completed in a given time frame) to avoid some of the local optimization that could occur for each user story.

For further reading on the Theory of Constraints, check out any of Goldratt's books. I highly recommend starting with The Goal which is also available on iTunes Canada as an audiobook for $2.95.

Subscribe to this blog by Email

Silent Brainstorming

I read an interesting article earlier this week that summarized some of the latest research on brainstorming. The research found that group brainstorming (out loud) doesn't restrict the amount of ideas generated, but it does restrict the variety of ideas. By contrast, brainstorming as individuals allows a greater variety of ideas to be generated. They also found that once the ideas were generated, having a group discussion about the ideas was beneficial in order to combine and improve upon the ideas. Here are some interesting quotes:

"Cognitive fixation causes people to focus on other people's ideas and are, inevitably, unable to come up with their own."

"If the goal is to come up with a bunch of unique ideas or solutions to problems, then the group should be split up so that individuals can come up with their own ideas and these ideas can later be combined with other members' ideas."

"...a group session after an individual session might be the optimal brainstorming technique."

So how can you combine both individual and group brainstorming? Here is an approach that I have been using that I've put together based on my experiences facilitating and participating in other sessions. This approach can be used for any brainstorming session whether you are trying to generate user stories, ideas for a retrospective, or strategies for your community group.

Step 1: Establish the goal.
Make sure everyone understands the purpose of the brainstorming session. For many sessions this can be communicated to attendees before the meeting begins.

Note: If your group is larger than 10, I would recommend splitting the group up into several smaller groups for steps 2 through 5. The groups can present their best ideas to each other at the end of the exercise and re-open the discussion and voting at that point if appropriate.

Step 2. Individual (and silent) brainstorming.

Hand out post-it notes to everyone in the group. Ask each person to write down one idea per post-it until they run out of ideas. This part of the session should be performed in silence. There are a few cues to look for to understand when the group is done but the most consistent one I use is to watch their body language. When most of the group is leaning back or looking up, they are probably done. If you are having trouble reading their body language, a good rule of thumb is to wait until most people have at least 3-5 ideas written down. Also - be prepared with extra post-it notes in case someone runs out. I once had a participant say "I stopped thinking when I ran out stickies" ;).

Step 3. Describe your ideas
Once everyone has finished writing down their ideas, choose one person and ask them to describe their best idea and then place that post-it on the wall or the table. Continue going around the table asking each person to describe their top one idea until all ideas have been presented. It should take several rounds and each person will have the opportunity to present several ideas - one during each round. While the ideas are being described encourage everyone to keep writing additional ideas down. This allows the group to combine and improve upon ideas presented by others.

Step 4. Group the ideas
There are several ways to group the ideas depending on your group size.

a) If your group size is five or less I prefer using silent affinity grouping because it is fast and collaborative. Ask your team to silently group the ideas. Things that are similar to each other should be moved closer to each other. Things that are dissimilar to each other should be moved farther apart. Groups should form naturally and fairly easily. Once again, body language will help you see when they are done - usually 2-3 minutes.

b) If your group size is more than five I prefer to have one person group the post-its as they are presented because it is faster. Simply put the post-it near other post-its with similar ideas.

Once the groups are created you can name each group with a short title.

Step 5. Silent Voting
If you need to vote on the ideas or on the groups, I prefer using silent voting. Number each post-it and then ask each person to write down their top three on a post-it. Once all the votes are in, tabulate the votes to identify the top ideas.

Summary
This method of brainstorming combines the best of both individual and group brainstorming techniques and is consistent with the latest research. However, I initially started using it not because it conforms to the latest research but because it allows everyone to have a voice - the loud people can't dominate the conversation and the quiet people are given a way to contribute. That it reduces the effect of cognitive fixation when generating the initial list of ideas is an added benefit.

References:

• http://www.businessinsider.com/brainstorming-team-building-effectiveness-2012-1
• http://onlinelibrary.wiley.com/doi/10.1002/acp.1699/pdf
• I was videoed by InfoQ talking about Silent Brainstorming at SDEC12. Watch the video here.

User Scenarios and Lean Solutions

After reading the book Lean Solutions a few years ago it was easy to see that agile methodolgies are "Lean Solutions" in comparison to traditional methodologies, but I wondered how we could apply that knowledge to design and build Lean Solutions for our clients (yes, you can still build bad systems with agile). User Scenarios are one tool that can help.

Well written user scenarios put all the 'features' into a flow that is relevant to the user's value stream. They can help us design a solution as a unified value stream rather than just a bunch of features put together. From Lean Solutions:

"Companies must provide the goods and services consumers actually want, when and where they are wanted, without burdening the consumer."

For more information and an example, check out Jeff Patton's stickyminds article.