What I Learned Pairing On A Workshop
by Lisa Crispin
I had the privilege of pairing with Abby Bangser to create and facilitate a half-day workshop at TestBash 2016: "Building Quality In with Distributed Teams". Bhagya Mudiyanselage, one of the workshop participants, wrote about her experiences in the workshop . I learned a lot by preparing and facilitating this workshop with Abby, and not only about building in quality on distributed teams!
Abby and I are a distributed team ourselves, separated by 7 time zones, making logistics tricky. Both of us were presenters (separately) at Agile Testing Days last November. The conference was jam-packed with activities, but Abby and I managed to carve out some time to make a plan for preparing our TestBash workshop. Since I'm not the most organized person, and in fact am a terrible procrastinator, I was glad that Abby suggested setting some milestones for pairing via Skype, mind mapping our session, creating exercises and a slide deck, rehearsing the session. Sticking to this schedule pretty well helped us get ready in time and feel confident about how our workshop would go. I learned some good habits around managing my time through this process.
Abby set up a shared Google spreadsheet with different tabs for our high level goals, proposed exercises, resources for exercises, open questions, and feedback from run-thrus of exercises. We accumulated more shared documents as we looked at different games and exercises. We also had one for action items. We crossed them off as we went, which gave us a nice sense of accomplishment.
For example, for the coming week ending January 13:
- Abby will try out an iteration of the coloring game (1/14 YIPEE!)
- Lisa will schedule a try-out of the game
- Think about open questions and answers to them
- Keep working on slides
- Look for images to color (Abby sent 1/13)
- I found these techniques helpful and since I frequently pair with others on conference talks, they are coming in handy.
Keep An Open Mind
Like a lot of humans, I am tempted to stay inside my comfort zone. I have some "tried and true" (at least, to me) techniques for workshops and tend to stick to them. When Abby proposed using a "Speed Car - Abyss" retro format during our workshop, I shied away at first. It seemed complicated, and I worried it wouldn't fit with a half day workshop. I wanted to reject it right away. But as I thought about it more, I realized I needed to be willing to consider new ideas. Abby had good ideas about how the retro could help participants evaluate what happened during the workshop and have more concrete ideas to take away and try with their own teams. It ended up working splendidly.
Early in the workshop we identified issues that might drag our distributed teams down into the abyss. As we paused for retrospectives during the simulation, participants identified obstacles holding them back and techniques that were helping them move forward. At the end, we discussed activities that could help our teams build that bridge over the abyss.
Another area where I had to force myself out of my comfort zone was the simulation exercise. We wanted to simulate a distributed environment, provide learning opportunities and hands-on practice. The simulation was the heart of our workshop. If it failed, participants would not learn much.
I have some exercise activities that I've used before and feel confident I can make work. We talked about several ideas, like having people draw pictures, or put together shapes. Abby suggested having the teams color pictures. That seemed a bit silly to me at first, I couldn't see how it would simulate real work. But Abby pointed out how some images looked complicated, but had a clear key as to which colors should be used where. Other images looked super simple, but there was no guidance about color -- the product owner needed to provide that information and they could turn out to be quite complex. That's pretty much like real work! And again, Abby's coloring idea worked really well.
It was a good lesson to me to remember to be open to new ideas, even if they seem scary, silly or difficult.
Practice, Practice, Practice
When I pair with someone, I want to make sure I don't let them down. That motivates me to put more effort into my preparation and practice. Again, Abby's organizational skills were a plus.
I confess that I often do exercises that are new to me during conference sessions without trying them out beforehand, I just hope for the best and I've been lucky. However, Abby thought we should try out the coloring exercises. We each did a dry run with volunteer coworkers. This was so important as it helped us get the timings right and find ways to make the simulation more realistic.
We also rehearsed the talking portions of our workshop with our slides via Skype at least a couple of times, as well as each of us practicing individually. I still fluffed a few things on the day, but I expect participants didn't notice. All the practice helped our confidence.
It's a good reminder to me that like a lot of things in software development, making a bigger investment at the start can pay off with better results in the end! I've already used this learning point. I'm pairing with JoEllen Carter on a session at Mile High Agile. It's only an hour long, so we were able to do a run thru for a few volunteer participants at lunchtime.
Pair presenting means built-in help and support. However, our distributed team simulation meant having half of our participants go "offshore" into separate rooms. It would be tricky to facilitate four different table groups in three different rooms through a lengthy simulation.
TestBash kindly provided us with one volunteer, Laura Mocanita. One of Abby's colleagues, Srivinas Murty, kindly offered to help as well. Abby wrote up instructions for our volunteer facilitators and sent them in advance (another smart idea I will use myself!) They each facilitated one of the "offshore" teams in our distributed simulation. They were also superb observers, sharing what they saw happen in the "offshore" teams, as well as their own experiences working in distributed teams.
I often find it hard to ask for help. I don't want to be a burden or bother people. But the truth is, people usually want to help, and they can add a lot of value. Hopefully they also got value from helping us out.
Prepare To Be Surprised
The TestBash workshop venues were scattered around the area near Brighton Dome. I scoped ours out the day before, which is good because addresses in England are numbered in a different pattern than ours. I arrived bright and early on the day to discover the facility was ideal for our workshop. We had a perfect size room for the main part, and two other areas for the "remote" teams in our distributed simulation. We had the essential good wifi (our teams would have to communicate by video conference in the simulation) and plenty of flip charts, markers, sticky notes and the like. I always travel with my own supply of Sharpies and stickies, but it's nice when the venue has generous supplies.
In our simulation, we divided the room (22 people) into two teams, then each team subdivided (by table group) into the "onshore" and "offshore" teams. Abby played the Product Owner role for one onshore team, and I was PO for the other one. We followed a typical pattern of holding an inception followed by three rounds of IPM, iteration, showcase/demo and retrospective.
We threw in some twists to cause the type of pain that real distributed teams experience. We were surprised at the spontaneous problems that also arose -- just like real life! Here's an example. The "development" consisted of coloring pictures, similar to those in a coloring book. After the first IPM, we gave each onshore team two boxes of 24-count crayons, and each offshore team got colored felt-tip markers. Technological differences! But my onshore team, not realizing their offshore team had colored markers, sent them one of their boxes of crayons. As the PO, I told them they should get their crayons back, because the offshore team had to use the markers. They "emailed" their offshore team (email meant walking over a note in an envelope) to ask for the crayons. But the offshore team, thinking they should use crayons, only sent back half of them. Not only was the onshore team short of crayons, which slowed them down, the offshore team delivered crayon-colored pictures, which I (a very picky PO) rejected as too messy. We hadn't expected this type of miscommunication, but it happens on real distributed teams too, right?
After the first two iterations, we brought everyone back into the room to reflect on how the work was going. Participants talked about what was getting air in their metaphorical speed car parachute, and what helped power the speed car's engine. We were surprised at how quickly the conversation became about "us" and "them". Though it was done in good humor, it was a powerful reminder of how we humans tend to react when under pressure and unable to collaborate closely. Thinking about this later on, Abby and I agreed we should have done more as facilitators to bring out the positive aspects of how the teams worked in the simulation.
With all our preparation, I expected our workshop would go well, and that participants would get new insights into how to test effectively in distributed teams. I was pleasantly surprised at the amount of positive and enthusiastic feedback we received. Abby and I worked hard to plan, collaborate, experiment, leverage our diverse experience, practice and get help so that we could provide a great learning opportunity. I'm not surprised at how much I learned in the process!
About Lisa Crispin
Lisa Crispin (@lisacrispin) is a tester who enjoys sharing her experiences and learning from others. She is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley, 2014) and Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009). Lisa is a tester on a fabulous agile team. She specializes in showing testers and agile teams how testers can add value and how to guide development with business-facing tests. Her mission is to bring agile joy to the software testing world and testing joy to the agile development world. In 2012, she was voted by her peers as the Most Influential Agile Testing Professional Person, and given this award at Agile Testing Days.