Alistair: We learned a lot on our last project about testing. We should do a presentation.
Jason: Great! How about next month, June?
Alistair: Hold on. That's too soon.
[Next morning]
Jason: Alistair, I signed us up to present in July.
Alistair: Uh...okay.
My colleague, Alistair McKinnell, and I did a presentation on testing patterns in July. We did the same presentation again in September. I had set out to inform other developers, but was surprised at how much I learned in the process. This post documents my experience and how I learned the value of not being attached to ideas, and how to make a more compelling presentation.
The Value of Collaboration
Alistair and I share a passion for unit testing. We wanted to share ideas and techniques that we had learned while working together. We wanted to share our experience of using the patterns from the book xUnit Test Patterns. We signed up to do a presentation at our company. We wanted to highlight BDD, test-first, JUnit tricks, jMock, 4-phase tests, pairing with a navigator list, and more.
Alistair and I got together a few times to talk about our presentation. The first time we got together, Alistair brought index cards. We wrote down what we wanted to present, and moved the cards around, playing with the structure. I wanted to write a lot of details on those index cards, but Alistair was happy with just a word or two. He had a good sense of what was the appropriate level of granularity for the ideas we were discussing and explicitly refrained from committing to particular ideas early in our discussions. This became clear to me when we met the second time, and we didn't bother using the index cards from the first meeting. We just wrote down new ones. Each time we met, we ended up creating a new (and better) presentation. From Alistair, I learned the value of not being attached to ideas, and to trust what emerges from the collaboration and the moment.
The Presentation
We structured the presentation into two parts.
In the first part of the presentation, we planned to make a mind map on a white board seeded with the word "Testing", using the audience to build the mind map. Our intention of this exercise was to engage the audience, to recognize the larger landscape of testing, and to delineate the context for the rest of our presentation, which was to be about JUnit testing. Due to the nervousness of show time pressure, we forgot the point of the white board exercise, and transitioned into the second part of the presentation without actually describing how our presentation related to the broader field of testing.
The second part of the presentation was to be a pairing session--Alistair navigating, and myself driving. We intended to illustrate the effectiveness (and joy) of test-first development using the myriad of techniques we'd developed over the last few months.
Our big emotional take away was the collaborative nature of pairing, and how spontaneous and continuous conversation between the pair leads to a steady stream of small decisions out of which the code emerges.
The audience threw us for a loop. In all of our pairing sessions, our conversation was rich with ideas about the code and how we pair. We expected this to happen, since it happened every time we did a dry run to prepare for the presentation. This dynamic never happened. In hindsight, it's obvious--there was little communication between Alistair and myself during the presentation. The central exchange was between the two of us and the audience. The exchange with the audience was actually a very positive highlight of the presentation. However, the pairing dynamics that we expected, never occurred, and we were left without a strong takeaway--the prepared one about pairing did not fit well with our "pairing" session.
A More Compelling Presentation
Our first presentation was in July. A couple months passed, and we were scheduled to present again, this time to a larger audience in Toronto. In the two months that passed, we had read Made to Stick.
We asked people who had seen our first presentation what they remember about it. For the most part, no one remembers any detailed ideas, and BDD is the only general concept that people recall. Alistair and I resolved to apply the ideas from 'Made to Stick' to make our presentation compelling. In particular, we aimed to incorporate stories, be more concrete, and to introduce a knowledge gap.
So for the next presentation, we removed a lot of the content, and distilled our presentation to a single message around which the entire presentation was structured--by aligning your team's testing philosophy, you could minimize tactical disagreements and be more productive. Our presentation title changed from "Testing Patterns" to "What is your testing philosophy?". The title creates a knowledge gap, a mystery that needs to answered. We wanted people to think, "I don't have a testing philosophy. How do I get one?".
Our message was centered on a story--You find yourself pairing with Jane. Both of you are interested in testing. However, you find yourself in a debate about how to name the test method, and then another debate about whether to write the test first, and another debate about when to stop writing tests. An hour later, and you and Jane have very little code to show.
Our presentation would show that a lot of tactical discussions around testing are rooted in differences in philosophy and that it's more fruitful to raise the discussion from the level of tactics to one of philosophy, and that you can frame a testing philosophy discussion around goals. Our takeaway changed from a very abstract notion on the nature of pairing to "How to Align your Team's Testing Philosophy".
Conclusion
If you are interested in the presentation of ideas, I highly recommend Made to Stick.
Presentations are really forcing functions for collaboration and learning. If you want to learn about something, I recommend signing up to do a presentation on that topic, and enlisting a co-presenter.
Presenting is about sharing your passion, and it's about learning from your audience, and your collaborators.