Last week, Moss Colum and Laura Dean gave the Boston Software Craftsmanship group a sneak peak of their Agile 2010 Pairing Games as Intentional Practice session. And, as a bonus, we got to try the games out during our code kata.
I know what you’re thinking, Abby, you’re a freakin’ geek. And I’m okay with that. But it was WAY fun so I wanted to share.
I love the premise behind this. A lot of us struggle when pairing with another person, so let’s create games we can play (intentional practice) to help us get better at the parts we’re struggling with.
I think we can learn not only how to pair better, but also how to incorporate games into our work as a way to continuously improve ourselves and how we collaborate with others.
Ping Pong: Establishing Cadence & Keeping Both People Engaged
This is a pretty common technique in pair programming, where our goal is to test-drive our development. That means we think about the next step we need to complete. We write a test to validate it. And then we write the code to make it pass.
So, in Ping Pong, I write a failing test and pass the keyboard to you. You make it pass, write the next failing test and pass the keyboard back to me to make it pass. Lather, rinse, repeat. This gets us into a good cadence and keeps us moving. It also helps to make sure one person isn’t dominating and keeps both people engaged.
Farsighted Navigator: Building Respect
Ever “pair” with someone who only wants to tell you what to do? Probably not so much pairing at that point — you know, taking advantage of having two capable minds working together — as just providing a lackey for the know-it-all.
In pair programming there are two roles: the driver is the one typing in the code. The navigator (or observer) takes a more strategic viewpoint, thinking of ideas for improvement and possible roadblocks, thus serving as a kind of safety-net and guide so the driver can focus on the details of making the current code work.
This can work great when the people each do their own role and trust their pair to do the other. But, especially as techies, we really like to focus on the details of how to implement something. This makes us pretty sucky as navigators.
So, how do we improve? We create a game as intentional practice to help us become better navigators. In Farsighted Navigator, we force the navigator to keep all of his talk to a level higher then the methods/code (implementation details). This not only helps us build our skills at navigating, but also reminds us that others really can be competent programmers if we’d just shush up and let them code. Thus, it’s also a good way to build respect on the team.
Silent Programming: Just Do It
A great thing about pairing is that you now have another person to talk to, to bounce ideas off of. A bad thing about pairing is that this can revert into discussions that last way longer than necessary and you really need to just stop yacking and start doing. One way to do that is explicitly: no more talking, just start coding. If there’s a large amount of uncertainty, set a time box and give yourself permission to revert the changes at the end if they didn’t make sense. Just something to get going.
This one was fun to play. As the name implies, no talking allowed! (although I did end up drawing pretty pictures to show my pair when we played this). You have to switch regularly. Set a timer to go off every 3 minutes and if you haven’t switched yet when it goes off, switch then.
Yes, And…
My favorite part of the Silent Programming game was that we had a “yes, and” rule. This comes from (theater/jazz) improv where you take what someone has done and you build on top of it. Keith Sawyer describes this notion really well in Group Genius. We’re so used to ignoring what someone else just said or did because we have our own idea about the best way to do it that we wait for them to finish and then say “no, but… <we should do it this other way>.”
If you can imagine watching an improv theatre group doing “no, but” it would make for a pretty lousy act. All the actions would be in conflict and you’d never get to a coherent story line. Instead, if the actors had to use whatever others had done before them (guy puts on a funny hat, leans out the window and starts preaching random things, woman takes his hat and starts…), that it raises creativity to an entirely new level and can make for some pretty entertaining stories.
So, I think this was my favorite take away from the pairing games. We should practice “Yes, and” more often, not just in our pairing but within our teams.
Make Up Your Own: Games as Intentional Practice
Finally, Moss and Laura gave us some pointers for how we can make our own games as intentional practice.
Is something hard?
Make a rule that forces you to do it so you get better at it. Setup strict but simple steps to make sure you’re doing it right while you’re learning.
Is something helpful?
Make one pair responsible for it or find something that creates opportunities to do it.
Is something harmful?
Make a rule that prevents it at all costs. Or, try the opposite and make a rule that forces you to do it for a certain amount of time and see what happens.
Is something missing?
Find a way to structure your work so that it includes it, or to prompt it periodically.
Learn More About Pairing
Devs: go see Moss & Laura in Pairing Games as Intentional Practice
Devs and Testers: come to Dawn Cannan & I’s hands-on workshop: Better Story Testing through Dev-Tester Pairing
Do you think we can apply any of these lessons to other types of complex tasks that we do closely with other people? Can you think of other games that would improve collaboration?
—
Photo credit: Geisha Playing Ping Pong: Shohei Otomo
The post Pair Programming Games appeared first on The Hacker Chick Blog.
