As you may have noticed from my tweets, LinkedIn posts, Facebook posts, or chattering in person, I’m finally caving in to the peer pressure and organizing a local Atlanta, GA, USA tester meetup. Kind tester friends over at Software Testing Club have offered us help promoting and we are co-branding as Software Testing Club Atlanta. Please join us for our first Meetup on Tuesday, October 15, 2013 from 6 to 9 PM EDT. (Note: This meetup is not taking place in the UK, so sorry to all the usual STC attendees! We’re trying something new here. Also, the generated calendar appointment appears to be UK time rather than using the location’s local time. We’re meeting in the evening!)
Software Testing Club is crossing the pond to the United States! Our first Atlanta, GA meetup will be in space loaned by a tester friend, so we’re heading up to Alpharetta (center of gravity for the interested parties).
For our first meetup, our format will be a Lean Coffee, so bring your interests and ideas for discussion. We’ll explore this format and get to know each other over pizza and beer. (So I guess we could call it Lean Beer if you like…)
On the first full day of STARWest 2013, I ended up at home with my sick son. (Stomach bug. Boo.) Fortunately, most of the excitement had passed by morning and the day turned out to be blessedly restful, which was essential for this sleepy mom keeping vigil.
We rolled out of bed and sat on the couch watching a cartoon in companionable silence while I poked about on Twitter to find information on the morning’s Lean Coffee to attempt virtual attendance. Since it turned out to be a Google Hangout, my son became much more interested in paying attention, selecting various digital accessories for me – much to the amusement of the other attendees. (Son’s first Lean Coffee? Check. Wearing a digital monocle? Check. Winning at parenting? Check!)
As with any remote conferencing system I’ve ever used, the setup and logistics had their challenges, but I was happy to be included in the event in this small way. The one topic that I could clearly hear concerned sharing conference learnings after returning home.
The classic: presentation to the team.
Many people have blogged about writing – or presenting – a great trip report. Usually these start out with advice for writing your conference attendance proposal to include some language about teaching what you learn, perhaps at the prompting of your boss. At the conference, you take great notes, perhaps even writing up your report during a layover on the way home. Upon your return to the real world, still on a conference high, you set out the conquer your problems with the grand visions of a better work life only to confront business as usual… which you will somehow overcome in a single hour or two of lecturing? It’s a rude awakening. Somehow the top-down decision that the team will learn – from you. right now. – isn’t quite working out. So how do you overcome the resistance to change and really bring home useful lessons?
The subtle: solo experiments as exemplars.
A tactic I prefer is coming home with a list of things to try “on Monday” when I’m back in the office. I think of this as a series of small experiments. Matt suggests keeping these experiments isolated to your day-to-day work in order to improve results without running into the dreaded inertia of the system. As they say, big wheels turn slowly. I can certainly see his argument there since past attempts to suggest alternate approaches that radically changed others’ tasks haven’t really worked out for me. I feel a lot of ownership of my experiments and the experiences have opened up my thinking to additional new techniques, approaches, and strategies. Is your pen mightier than the the sword? Will your report really sway your audience? I certainly have tried this option in the past, but teams may find that approach tired, just one more meeting to attend.
The new shiny approach that I’m currently tackling is making connections among different presentations and topics to connect them in ways that seem particularly relevant to my work team’s context. My current experiment is a series of smaller presentations, complete with food and succinct snippets (the TL;DR) in emails that will link to blog posts (the deets). Gradual exposure seems better than bombarding a team with new information in a one-time brain dump. I just hope no one gets sick of my weekly missives!
I’m putting together Lunch-n-Learn presentations and weekly email/blogs to distribute. Less info dump, more learning #leancoffee#starwest
As the conference delegates adjourned to attend the regular sessions, I remained sitting with my son. It might have been the exhaustion talking, but when he asked me for my mobile phone I gave in. Within minutes, he found an odd interaction (bug?) in the mobile Hangouts app and shortly afterward froze Angry Birds with a feathered missile in mid-arc. Natural born tester, I tell ya. Making his momma so proud it was easy to forget the sickness and fatigue.
As Agile2013 considers itself a best in class kind of conference “designed to provide all Agile Team Members, Developers, Managers and Executives with proven, practical knowledge”, the track committees select from a large pool of applicants and prefer vetted content that has worked its way up from local meetings to conferences. I have only one talk that fits this criteria since I presented Big Visible Testing as an emerging topic at CAST 2012. I developed several versions of this talk subsequent to that event and doing so had given me confidence that I would be able to provide valuable information in the time allotted and still leave enough time for attendees to ask questions and to give feedback on what information resonated with them.
I worked to carefully craft this proposal for the experience reports track, knowing that if I were selected that I would have a formal IEEE-style paper to write. Fortunately, my talk made the cut and I began the writing process with my intrepid “shepherd” Nanette Brown. I wasn’t sure where to begin with writing a formal paper, but Nanette encouraged me to simply begin to tell the story and worry about the formatting later. This proved to be wise advice since telling a compelling story is the most important task. Harkening back to my high school and early college papers, I found myself wading through different but largely similar drafts of my story. I experimented with choosing a different starting point for the paper that I ultimately discarded, but it had served its purpose in breaking through my writer’s block. Focusing on how the story would be valuable to my readers helped to hone in on sequencing and language selection. Once I had the prose sorted out, I began to shape the layout according to the publication standards and decided to include photographs from my presentation – the story is about big visible charts after all!
Investing sufficient time in the formal paper made preparing the presentation more about strong simple visuals. I have discovered my own interest in information visualization so prototyping different slide possibilities and testing them out with colleagues was (mostly) fun. I’m still not quitting my day job to go into slide deck production. Sorry to disappoint!
Despite all of this preparation, I couldn’t sit still at dinner the night before my presentation and barely slept that night. I woke before the sunrise and tried to school my mind to be calm, cool, and collected while the butterflies in my stomach were trying to escape. This was definitely the most challenging work of presenting!
As a first time speaker, I didn’t know what to expect, so I set my talk’s acceptance criteria as a rather low bar:
Someone shows up
No one hates it enough to leave a red card as feedback
When I walked into my room in the conference center, a lone Agile2013 attendee was waiting for me. Having him ready to go encouraged me to say hello to each of the people who came to my presentation, which in turn changed the people in the room from a terrifying Audience into many friends, both new and old. I think I managed not to speed through my slides despite my tendency to chatter when I’m nervous. I couldn’t stay trapped behind my podium and walked around to interact with my slides and to involve my audience more in the conversation. Sadly, I can’t share my energy with you since I forgot to record it. Oh well. Next time!
The vanity metrics
At 10 minutes into the presentation, 50 people had come to hear me speak and at 60 minutes I had somehow gained another 7 to end at 57 people. Thanks so much for your kind attention! I hope I made it worth your while…
43 people stopped to give me the simple good-indifferent-bad feedback of the color-coded cards (which I liked as a simple vote about a presentation) and I received 37 green cards and 6 yellow – with no red cards! Whoo hoo!
Words of Encouragement
Two people kindly wrote out specific feedback for me and I want to share that with you in detail, hoping to elicit some late feedback from attendees who might like to share at this point (Agree or disagree, I want to hear from you!)
Feedback Card #1:
– Best session so far!
– Great presenter – great information – great facilitator
– Would like to see future sessions by this speaker
Feedback Card #2:
Great Talk – speaker very endearing, Her passion for the subject matter is obvious.
A fresh perspective of how Developers and Testers should interact.
Should find ways to engage the audience
Someone else got a kick out of my saying, “I’m serious about my stickies.” and left their notes behind on the table after leaving. So thanks for sharing that. 🙂
One friend spoke to me afterward with some helpful feedback about word choice and non-native English speakers. When I was writing my talk, I was trying to focus on people who would be likely audience members, but I had not considered that aspect of the Agile2013 crowd. Since I was simply speaking off the cuff, I ended up using some words that would have fit in at our dinner table growing up but that would make for tougher translation. And yet, I got some wonderful feedback from Hiroyuki Ito about the “kaizen” he said I made. I can’t read it directly, but Google Translate assures me it’s good stuff. 🙂
Finally, I discovered that my relationship with a linear slide deck is not a comfortable one. I wanted to be flexible in referencing each of the slides and having to sequence them hampered my ability to respond easily with visuals when discussing questions or improvising during my talk. I haven’t experimented with other presentation options, but I hope there’s an easy solution out there.
During the year and a half of experimentation that included the big visible charts that are included in this slide deck, I read over the following resources, only some of which would easily fit into the IEEE format. This is the full bibliography of my research, as far as I have been able to track down my sources. (At the time, I wasn’t expecting to cite them for anyone else, so I probably didn’t bookmark everything I read.) I hope the following links will prove helpful to you in developing your own big visible charts. Let me know how it goes! And please share any sources that you find helpful. I’m always looking for new inspiration.
My first dev team was an XP dev team that dogfooded our own digital signage product to display success/failure for the thousands of unit tests in the suite (i.e. single flag for whole suite red/green).
Other eXtreme Programming big visible charts
Although the above resources were all I knew at the time I began my experiments, as I prepared my IEEE paper for the Agile2013 conference proceedings, I was tracking down my sources and came across these other relevant pages & posts that have given me some great ideas of things to try next!
After some discussion in my session about suggesting solutions for distributed teams, I was looking for some digital implementations of big visible charts, but I don’t know how these would work out for you.