Est testing parfait?

I heard that Gerry Weinberg has an exercise called “Mary had a little lamb,” in which you analyze each word in the sentence to elicit implicit meaning that might be important. This sounded interesting enough to try, so when the opportunity came to propose a topic at Test Retreat 2013 I went for it. My topic “Is testing for me?” didn’t end up formally scheduled but made a nice interstitial topic to discuss with those milling about in the main room.

I chopped the sentence into separate words and wrote them top-to-bottom on a large sticky note. Then, instead of giving some sort of prepared remarks, I elicited brainstorming from the gathered participants. Having received interesting feedback on my professional and personal strengths at Agile2013 that had left me questioning how best to use my evil powers for good, I wanted to hear how others were thinking about the testing field and how it fit them.

The resulting scrawled notes ended up a mindmap, the path of least resistance for me. I won’t say the discussion solved all my problems, but it did give me some direction for future exploration – exploration that might also be helpful to a newbie wondering whether to pursue a career in testing.

Is testing for me?Which brings me to some interesting recent events:

I started composing a list of things I’d recommend to people just starting out as testers to help them to evaluate whether to continue. I wanted to encourage them to jump right in but also think big, not waiting them to wait 5 years to reach out to the wider world of testing (like I did).

Here’s my current list. I blogged about various experiments I tried, so you can read for yourself to see what it’s like to select what’s a good starting point for you.

No matter how many times I think I’ve found all the meaning in my testing career, suddenly I realize there are more layers… but like a parfait, not an onion.

Donkey: Oh, you both have LAYERS. Oh. You know, not everybody like onions. What about cake? Everybody loves cake!
Shrek: I don’t care what everyone else likes! Ogres are not like cakes.
Donkey: You know what ELSE everybody likes? Parfaits! Have you ever met a person, you say, “Let’s get some parfait,” they say, “Hell no, I don’t like no parfait”? Parfaits are delicious!
Shrek: NO! You dense, irritating, miniature beast of burden! Ogres are like onions! End of story! Bye-bye! See ya later.
Donkey: Parfait’s gotta be the most delicious thing on the whole damn planet! – Shrek

Thanks for the inspiration to write, EmJayKay80 and Niyi!

STC ATL Lean Coffee #1

STCATLMeetup1-DotVotingOver the last few years, I have been getting to know other software testers here in Atlanta. Frequently, beginning this new acquaintance is such a positive experience that the other tester urges finding others similar to us to meet more regularly. This is such a common outcome that I am no longer surprised when first conversations end this way.

I don’t have much experience with the particulars of sifting through a large tech community for people interested in hanging out during their personal time to chat about testing software. However, when others insist on giving you a boost, it’s harder to say no.

I have demurred all these requests until now. Eventually it seemed silly to continue to turn down the genuine offers of resources, energy, and enthusiasm. I almost felt bad about denying people the community they so clearly craved. So here we are.

I love meeting new people and engaging them in conversations. However, I realize not everyone is comfortable doing that. I’ve noticed that having a structure to interactions can reduce the social barriers for those who might otherwise hang back.

At Agile2013, I noticed that Lean Coffee was an easy way to get to know a group of strangers, so I thought it would be a good place to start for the newly formed Software Test Club Atlanta.

I have participated in several Lean Coffee events run by different facilitators. I liked the simple style and frequent feedback so much that it was the first thing I brought back with me to work after Agile2013. The format proved fruitful for an internal meeting and so it seemed like a good idea for starting this local meetup.

Another good idea for starting something new is affiliating with established allies. Since one of my benefactors was part of the Software Testing Club community, I thought co-branding made a lot of sense. I led the idea of extending their brand to the United States since doing so would bring more people together worldwide than I could on my own. I wanted our nascent local group to be connected to the larger world of testing enthusiasts from the beginning. That would support the new members’ sense that each of them is not alone, the connection that drove creating this group in the first place. This is really a community building itself. I just happen to be in the center of it.

I love helping people to connect deeply with one another, so it seems only natural to put in the effort of providing the means for others to come together. Now that I work in social media, setting up channels for others to find us and join in the discussion was my first step. I want to be discoverable so that other local testers who feel the need for connection won’t have to wait so long for me to happen along.

I really appreciate that local businesses are supporting our efforts to make time to tackle difficult questions in testing and to share what we’ve learned through our professional and personal experiences. So you will definitely hear me being vocal about thanking them. I wouldn’t choose to do this alone and I’m encouraged that others think this is a cause worth the investment. I’m confident that we’re building a strong community of thoughtful and curious folks who give each other’s ideas a chance.

At our first meeting, I facilitated the Lean Coffee format since I didn’t want anyone to feel put on the spot to take over something they hadn’t experienced. Since we had 15 other in-person attendees and 3 online folks, this was a much larger group than normal. Although I recognized that groups of this size would normally split, I thought keeping everyone together would be better for cohesiveness.

We did use a simple personal kanban board. Each person had a chance to contribute topics. Due to the size of the group, each person had 3 dots to vote on which topics had priority. We established a 5 minute interval between votes to continue. Then, I added a “mercy kill” rule that after 10 minutes we had to move on to the next topic. I wanted everyone to experience the variety of Lean Coffee and knew that our topics were so complex that they could easily take over the entire time we had to meet. Those topics we still wanted to pursue went into our future meeting backlog.

As a result, we covered all of the topics that had received a vote. When items in the To Do column had an equal number of votes, I picked one to be the next to proceed to the In Progress column. Any topics we had covered sufficiently went into our Done column.

While this execution wasn’t a strict interpretation of Lean Coffee, it was a perfect adaptation to our purposes. The conversations continued after we had officially ended and people are looking forward to getting together again next month. We had lots of leftover pizza and beer, possibly because we were too engaged in the interaction to step away to enjoy the refreshments. All in all, it was a great investment of my time and I look forward to doing this again and again.

Please join us again this coming Thursday for another rousing Lean Coffee! We will have a WebEx available for virtual attendees, so tweet us to let us know you want to join in. See you then! Or on Twitter, Software Testing Club, Facebook, Google+, LinkedIn, etc

Software Testing Club Atlanta’s 1st Lean Coffee topics

  • 7 dots:
  • 5 dots:
    • (4th) Testing in SAFe
  • 3 dots:
    • (2nd) ATDD and/or BDD
    • (2nd) Specification by Example – getting started
    • (3rd) Exploratory testing
    • (5th) Testing in Kanban – its own column? encourages handoffs?
    • (6th) Test Manager Role on Agile Team
    • (7th) How to integrate off-shore testers w/agile teams
    • (8th) Hiring GREAT people – finding testers
    • Logic Flow Analysis and test coverage
  • 2 dots:
    • (3rd) What is breakdown of time/resources for: exploratory/scripted/automated testing (rough %)
    • (9th) Test/programmer pairing – success stories? Does it work?
    • (10th) Testing Meetups near us and around
    • Creating User Acceptance Testing
  • 1 dot:
    • Let’s get speakers! Topics?
    • What do you use to test multiple browsers?
  • No votes:
    • When to Automate?
    • What avenues do people use to find out about testing methods/tools?
    • LAWST Workshop in Atlanta?
    • Developers don’t test (?!!) (What?!!)
    • Test metrics
    • Whole team testing – good idea? How to get it working?
    • Gov’t shutdown & testing

Guest author at AgileConnection

Check out my recent article Eat Your Veggies over at

Claire Moss shares with us a personal story on how using agile methods helped her family with managing meals and groceries. By using techniques like a Big Visible Chart, dinnertime for Moss’s family became less of a chore. Remember, nothing ever goes according to plan, but that’s true for any healthy team.

Here’s the big visible chart that turned our dinnertime struggles around:

Agile will FAIL

The closing keynote at CAST 2013 was Scott Barber and Rob Sabourin describing takeaways from each of the talks of the conference, bringing together many different talks into themes or striking moments. As a speaker, I was on tenterhooks waiting to find out what Scott would say about my talk. It was not what I expected, a moment from before my talk that he described as a “kick to the head” (in a good way):
Scott's Takeaway from my Walking Skeletons talk
He pointed out that I was emphasizing empathizing with people with different experience and perspective, which was important enough to say explicitly before I began my talk. So with that in mind, I want to talk about a foreign perspective I encountered at my other software conference of the year.

At Agile2013, someone taped large sheets of sketch paper to the wall with a large writing prompt:


to which many people replied in various ways during the week. Some of these responses were rebellious, resisting the seeming prophecy of failed agile. Others felt trapped by unresponsive or rigid organization behavior and hierarchy, industry regulation, or even customers. Contributors felt that companies with only a shallow understanding of agile or simply name-only “implementation” had no real difference in the way of working. Culture weighed heavily on the minds of attendees: belief, passion, desire, emotion, infighting, courage, trust, support, motivation, thinking. So people problems were at the heart of most expectations of failure.

To me, the most provocative perspectives I saw on that wall were not focusing on agile but on the demonstrated value delivered through whatever works, focusing on outcomes. Today, a friend pointed out a Mike Cottmeyer article from 2009 that discussed defining value in agile but at the enterprise level in terms of real business outcomes:

As an organization, we know that we need to deliver value as fast as possible… but we can’t figure out how to apply the small team concepts to our particular business problems. That’s why you get the classic “agile will never work here” comments. There is an inherent disconnect between the team level guidance agile methodologies talk about and the bigger concerns your senior executives are struggling with. There is a gap between value at the team level and value at the enterprise level.

Four years later, Agile2013 conference attendees are still wrestling articulating delivery of complex business objectives to business leaders. And while I also struggle with messaging how my work provides value to the enterprise, I’ve never experienced an agile transformation and so it hadn’t occurred to me to wonder whether agile could succeed. It’s always been business-as-usual, in my experience.

The full (transcribed) list from the Agile2013 wall:

  • We think we are “Agile”
  • The concept of “dedicated to one task at a time” is not supported!
  • They won’t change
    • Response: “They”? Maybe this is contributing to the problem
  • Because CEO manages with fear and intimidation
  • … Only focused on changes in development teams; not looking at whole value stream (product ideation & management)
  • No buy-in from the business
  • Duplicitous product owners (two masters)
  • because of our culture
    • Response: √
  • because my customer prefers waterfall…
  • Because the company wears “agile” as a label and yet does nothing to remove the bureaucracy and obstacles teams face daily while trying to implement agile.
    • Response: √
  • We lose trust in each other
  • … Adoption is done because of convenience not because of conviction.
  • We are different
    • Response: … Just like everyone else who has done it.
  • Our egos are bigger & more important than the company goals
  • A re-org will set us back to the beginning, again and again. (weekly)
    • Response: √
  • Of me.
  • …Insufficient support from leadership
    • Response: Totally agree
  • Different part of the biz use different types of agile
  • Deeply hierarchy…. Project leader doesn’t want Agile.
  • my leadership team no longer believes in it 🙁
  • … it’s counterintuitive & hard to practice
  • Because agile is a state of being… NOT doing! Agile is grossly misunderstood… SADLY!
  • … because Agile is not the goal. Agile is simply a MEANS to and END
    • Response: Agree!
  • We only fund CAPITAL projects
  • Because I just think on the consequence not the cause. We should be able to teach the noble truth behind agile methods. Teach that discipline is not a fantasy. If we try hard as a team we can achieve anything. – She Liang
  • My manager has to assign work to the team
  • It does not support SECURE software (ISO27000 or code analyzers)
  • They don’t want to change. & no lean leadership.
  • Too much focus on the mechanics of the process. Not enough on the motivation/passion behind it.
    • Response: +1
  • We have not explained the ‘why’
  • Not everyone on our team understands it.
  • It won’t, because I work at Rackspace! 🙂
  • “Lack of Courage…”
  • We don’t want it badly enough
  • Because I’m writing on this wall & I think it will so it will
  • We can’t show the value
  • “What we do already works!?”
  • Crash at current (complex) business model
  • Jim
  • Strong and growing PMO traditional structure being instituted
  • We don’t think by ourselves. We need to think everyday, every time, everywhere!
    • Response: Agreed.
  • Our culture won’t *change*
    • Response: √

Q: Maybe someone can clarify that business model remark for me? I wasn’t quite sure what that said…

Fresh Perspective

fresh_princeI can’t remember what it was like to start working as a tester. Ten years later, the only impression I have left of that time is voracious learning. So yesterday’s debut of the ISST webinar series focusing on the first 2 weeks on the job as a tester was a good refresher for me.

Ben Kelly gave a description of two distinct new testers and their experiences of adjusting to the expectations for testers. This reminded me of Pradeep’s talk at CAST this year about his “baby shark” new testing trainees. I suppose that shouldn’t surprise me since they’re among the founding members of ISST.

Both emphasized that novices have an advantage: ignorance. While that doesn’t sound like a very positive description, one you might not want to claim for yourself, it resonates with me. Most of my professional progress has been made asking the dumb questions that filled in my ignorance, pointing me in the right direction rather than remaining stagnant.

But ignorance is not enough, merely lacking information one stagnates. Curiosity turns ignorance into action, transforming it into a powerful tool. (I think this is what people refer to as beginner’s mind, though I haven’t studied that concept myself.) Pradeep explains that newbies have a tactical advantage in not having been misled yet. Ben reminds us that while asking questions seems so simple it’s actually deep exploration of context, not just about business content but also about team expectations.

When Pradeep’s freshers (I think I’m using that right, right??) go out into the world to help start-ups with testing, they’re learning multiple contexts. This adds a bit of complexity to the already daunting task of acquiring testing skills. Sounds intimidating, doesn’t it? While these testers get on-the-job training, the start-ups experience the value of a context-driven testing approach focused on providing business value, which shifts from business to business.

Ben and Pradeep emphatically drilled us on providing information in the way the consumers can understand. Knowing that they have multiple audiences, testers must be excellent communicators. As an intuitive person, this intimidates me – and it sounds like other empathic testers may have similar trouble. I took my first stab at messaging about testing with members of my product team since that was most familiar to me. However, test reporting above the product team hasn’t been a big part of my career so far. My primary approach there has been getting to know the end users.

I know this webinar was aimed at less experienced testers, but I’m reminded that I could use a fresh approach myself. Like some (formal) practice in session debrief? Joining forces with sales for product demos? What approaches keep test reporting fresh for you?

Image credit

Testing For Humans? Try Empathy

Two months ago, Matt Heusser organized Test Retreat and I attended, along with 27 other testers open to new ideas and wanting to change the world. Sound a little ambitious? Let’s find out!

My first blog post in this series is about Michael Larsen‘s Testing For Humans, which he was unable to live blog due to presenting. 🙂 However, Michael did post Alessandra Moreira‘s notes in his live blog of the event.

Fortunately, I was able to live-tweet the talk that he described as:

Testing for Humans: It’s Sticky, Messy and Very Satisfying

Abstract: Software development is a beautiful thing. We often create amazing ideas and features that would be wonderful… if only those pesky humans that end up using, abusing, and mis-understanding our brilliant code weren’t part of the equation. Unfortunately, we’re all in the business of developing software for people (yes, even when it’s machine to machine communication, it serves human beings somewhere. What are some ways that we can approach testing software outside of the theoretical ideals, and actually come to grips with the fact that real human beings will be using these products? How can we really represent them, test for and on behalf of them, and actually bring in a feature that will not just make them happy, but represent the way they really and actually work, think and act?

Expected Deliverables: An excellent debate, some solid strategies we can all take home, and some “really good” practices that will be helpful in a variety of contexts.

My take-aways were:

    • People are imperfect so ideal users aren’t enough for testing.
    • By definition, a composite of many people (e.g. user persona) is a model.
    • Too many user descriptions based on small differences is overwhelming, not practical for testing.

On Wednesday night of this week, I joined Christin Wiedemann‘s regularly scheduled Skype test chat with some other lovely wonderful tester folks and we focused on empathy in testing. We wrestled our way to some working definitions of empathy and sympathy, which was much better than shallow agreement though it took a bit of time to establish. We agreed that testers need to observe, focus on, and understand users in order to serve them better. We find that empathy for our users and passion for our testing work go hand-in-hand since we care about helping people by producing good software.

Then we struggled with whether empathy is an innate trait of a person testing or whether empathy is a learnable skill that testers can develop through deliberate practice. (Go watch the video behind that link and come back to me.) We concluded that knowing what others are thinking and feeling, getting inside their skins, in the context of using the software is essential to good testing, though this might require a bit of perseverance. This can go a long way toward avoiding thinking we have enough information just because it’s all we know right now.

As I mentioned in the chat, I’ve found that user experience (UX) design is an amazing ally for testers. One tool that helped me to develop more empathy for my users is user personas. (Later, I found that forming user personas of my product teammates helped me to develop empathy for them as well.)

I immediately took to (end) user personas as a natural progression from user stories. After all, user stories are focused on value to and outcomes for a particular group of users. Describing those users more specifically in a user persona dovetailed nicely. Rather than some sterile requirements that never name the user, identifying a role – or, even better, a rich symbol such as a named primary persona – focuses the product team’s efforts on serving someone by helping us to understand the purpose of the work we do.

We also discussed interviewing users, visits to users, and experiential exercises as techniques to help us call upon empathy when we are testing. In my work history, I’ve been fortunate to hear about my UX team’s great work in a collaborative design workshop, to contribute to designing ad hoc personas for my product, to participate in a UX-led contextual inquiry, and to log actual usability sessions led by my product team’s UX designer. (Yes, my fast fingers came in handy. Yuk yuk.) My innovation days team developed a usability logging product that evolved from an existing solution I tested/used in those usability sessions, so I was a natural fit to test it. I’m curious about empathy maps but haven’t tried them myself yet.

It’s fair to say I’m a UX-infected tester. More than fair. I identify with the curiosity I see in the UX profession and I admire the courage to kill their darlings (carefully crafted designs) when evidence shows it is time to move on. After all, we’re not building this product to marvel at our own cleverness but instead to serve humans.

Image credit

Software Testing Club Atlanta

STC-300As 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…)

Illustrated guide to Lean Coffee
Lean Coffee Template


Depending on how it goes, we will consider other formats in the future. Bring your great ideas!

Tea Time

TeaCollectionA little history

So as you may have gathered, I’m an American. But not just any American. I’m from The South. In fact, I’m a very special kind of Southerner: the mythical Atlanta native. (Though some would argue that prevents me from being really Southern.) While most of you are likely to pass through our airport, I was born and raised here. That has resulted in a certain expectation when you mention the word tea (i.e. it should be used in the phrase “sweet tea”). Now Southern sweet tea isn’t “one lump or two” but more the kind of thing that induces diabetes. You don’t make it by the delicate little tea pot, you make it by the gallon and it’s always caffeinated. If you’re feeling really fancy, then you make sun tea. Carefully. Or you mix in a bit of lemonade and voilà, Arnold Palmer. The important thing to remember here is to serve it sweet – and cold.

Wait, what?

So you can imagine my curiosity when I discovered that most of the world drinks tea hot and brews it from “loose leaf” not tea bags. What’s that about? I had to find out! When I mentioned it to a friend, she showed up at my house bearing a beautiful enameled tea pot as a gift. It was time to learn a few things. I made a foray to a local tea shop and discovered that not only were there non-black tea options out there, but not everyone drinks it sweet. (Okay, so I might be livening things up here a bit, but it was still rather revelatory that this was a complex process.)

An app for that

I found out that the retail chain Teavana has an app. I decided I could use some help with brewing tea when my friends were not available to tell me what to do, so I downloaded it onto my smartphone. While the app clearly has a revenue purpose, driving you to purchase their detailed catalog of products, directing you to their online shop or to a local store, and showing recommendations for blending teas, it also has a tea timer. So I tapped on the brewing icon and stopped to investigate.

The first thing I noticed was the list of tea types that defaults to having Oolong selected. I don’t even know what oolong tea is, so I tried tapping the icon for additional information to no effect. I thought about referencing their catalog of Teas with its detailed descriptions of tea varieties in order to understand it better, but I didn’t see that option in the buttons at the bottom of the app. Accepting this usability problem in favor of actually making some tea right now, I went for the old standby and selected Black Tea. The generic black tea brewing instructions included measuring a volume of tea, but since I typically brew more than a cup at a time I had to do the math. No way to set up a preference for a full pot of tea here. The usability could use some love.

Some science

Then some perplexing data: 195 degrees. While I’m American and appreciate this default to the Fahrenheit temperature scale, I don’t have a kitchen thermometer, only human thermometers to use in case of illness. I was pretty sure that wouldn’t be suited to the purpose. (And it turns out there are thermometer testers! Don’t forget to calibrate!) Now I found myself heading to the internet for more data about water temperature. I’ll admit that I don’t know the temperature of boiling water in degrees Fahrenheit off the top of my head. And the first search result wikipedia article about boiling point, while interesting enough to open in another browser tab, weren’t helping me out here when what I wanted was a simple conversion. Okay, got it. 212 F is boiling and so too high for my black tea. Obviously I’d been doing it wrong my whole life. In the past, I’d just microwaved the water or boiled it on the stove, but now I should care about accuracy. Well that’s why I’m using the app in the first place, to gain some nuance in my tea preparation. The first step is admitting you have a problem.

Let’s do this!

So I get the water hot but not quite boiling and take it off the stove burner with my tea ball filled and ready to steep. Pressing the helpfully labeled Ready to Steep button takes me to an adorable screen that looks like the tea steeper they sell for a single cup brewing. I’m happy to go with it because pressing the Start Steeping button plays lovely music as it counts down and that music varies with the variety of tea. The animation of the water level adjusting with the tilt of the phone with bubbles rising up and tea drifting down is so cute – until my smartphone’s screen goes to sleep. The music cuts right off. I go to wake the phone up only to see the prompt to begin steeping again… What? I glance at the clock, wondering how long I’d played with rocking the phone back and forth. What time did I start brewing? Argh! For a tea novice, this flaw is fatal. My tea comes out just as satisfactory as usual, but I’ve had enough hassle with the app that it’s not a useful tool.

Clearly time to turn off the phone, sit back with my “cuppa,” and find some creative inspiration.

[Note: Although this post is not related to Tea-time with Testers, you should definitely go read that testing ezine too!]

Sick and Tired

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 novel: long and drawn out denouement.

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!

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.

Update from this morning’s Lean Coffee!


Image source

Story Time!

Agile2013-ClaireMossAs 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!

Performance anxiety

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:

    1. Someone shows up
    2. 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. 🙂

uneasy truce

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.

Image Credit