A few weeks ago, I went to agile NYC‘s Agile Day 2014. During the Open Space, I suggested a session titled “Sounds great in an ideal world, but…”
When the group convened, I started by noting the great number of times recently where a discussion of Agile ideas was followed by someone saying, “That sounds great in an ideal world, but it would never work for my company/department/team.” I asked if anyone had thoughts on why that answer was so pervasive, or how one might respond to such statements.
Early on, someone asked how I defined an ideal place. So, I wrote “the ideal place” in the center of a piece of paper and facilitated the group’s mind mapping of what that was. When the ideas started to peter out, I asked a question: “How many people feel that their current workplace is not this ideal place?” Almost everyone raised their hands. I looked at a guy with his hand down, thinking my wording had just been confusing, and asked, “Wait, so you are saying your workplace is ideal?” His response was so awesome:
“Well, no, but we’re always working to make it better. I mean, I don’t think you ever get to the ideal place. But if you are working toward it, that’s the best you can do.”
I’ll be honest: I started the session with soapboxy intentions. People talk about the ideal workplace like it exists out there, and as though their own problems would go away if they were hired there. My brilliant plan was to say to people: if you don’t think your world is ideal, it is up to you to make it ideal. But then this guy’s answer floored me with its beautiful simplicity. If you are working to make things better, you are already in the ideal place. I’ve heard variations on this before, but it really sank in for me this time. Suddenly, the ideal seemed a lot closer!
As for the guy who said this: I don’t know your full name. If you read this, please let me know: I’d love to credit you for saying this wonderful thing. And thanks!
A few years ago, I attended some training taught by Pete Behrens. He led us through a number of collaborative exercises. They had a number of common traits that I really liked:
- very simple instructions, so we wasted little time figuring out how to execute (and so the facilitator didn’t have to spend hours explaining);
- very short duration, so people didn’t get burned out, and so people did not deliberate at length over the value of the exercise;
- small groups (often pairs), so even quiet voices had room to come out; and
- frequent rotation, so the perspectives involved were constantly reshuffled.
I led a release planning meeting a month or two later, and I wanted to structure it around exercises sharing these characteristics. I set up 3-5 activities. Some were failures and some were so-so, but one stood out as valuable. It is still popping up here and there throughout our organization. Based on its longevity, I figure it’s worth sharing a little more widely.
To be clear: I honestly can’t remember if I made this up–inspired by Pete Behrens’ training–or simply repeated something he showed us. I’m not interested in credit! I just want more folks to know about this useful tool.
The exercise creates bursts of engaged discussion, typically about user stories. Typically, this exercise would be used in backlog grooming, but you can also use it in release planning or sprint planning.
- Write each story at the top of a blank sheet of paper.
- Break into pairs. Have one group of three if necessary.
- Give each group one of the stories.
- Give the groups five minutes to write down as many questions as they can about the story they have.
- After five minutes, each group passes their paper to the next. Give them 5 minutes to add questions to those written by the previous group.
- Continue repeating until each group has seen all of the distributed stories.
- Hand out the next set of stories, and repeat the exercise until you have gone through all stories. If you can, shuffle the groups before distributing new stories.
Let’s say your team of seven is grooming a set of nine stories. You would break into three groups (two pairs and one trio). You would hand out three stories, and over the course of 15 minutes rotate those stories through all three groups. You would then hand out three new stories and take another 15 minutes. And a final repetition would finish the last three stories. Nine stories reviewed by every team member in 45 minutes!
In the simplest case, the Product Owner can go answer the questions and adjust stories accordingly. Ideally, there is some later discussion of the answers. Some groups here have posted all the questions and their answers on a wiki for later review. Regardless, you have just gotten every team member thinking about every story in a very engaged way.
- Make sure people don’t try to answer the questions. This is just about asking the questions.
- If people do answer the question (say one person in the pair asks and the other happens to know the answer), make sure they write down the question anyway. Just because they now know the answer, they shouldn’t cheat the rest of the team of that knowledge!
- Regardless of how many stories/people you have, the math always works out that you need 5 minutes per story.
- If the number of stories isn’t equal to the number of groups, you will have to adjust. For example, with 10 stories, the example group could spend one round where one of the groups has two stories instead of one.
- Many questions identified very quickly.
- Helps make up for the impossibility of a Product Owner anticipating every question.
- Avoids backlog grooming meetings where only the Product Owner and one or two team members actually talk.
- Can take a meeting from boring to engaged, fast-paced, and even a little fun.
- Flashes a light into corners that usually only get illuminated partway through the sprint.
- Be careful not to let this be the only way your team discusses stories. Some open group discussion is great as well!
- “Query-Go-Round” is an awfully corny name for the exercise.
I’d love to hear about your experience if you give this a try. Also please post a comment if you come up with a new application/hack for the exercise. Have fun!