Speaking at StarEast and Better Software Conferences

Come visit me at the following conferences. I've also listed my schedule and the abstract of each talk.

STAREAST 2009 (Software Testing Analysis & Review)
4-8 May 2009
Orlando, FL

Agile Testing: Solving the Agilist's Dilemma
Wednesday May 6, 2009 1:45 p.m.

One problem with iterative software development is that teams are forced to write and test software incrementally—and repeatedly. Testers know that any change could break features in both obvious and hidden ways. Developers know that a change to their stable design is just around the corner. So, should we go back to designing software all up front and testing the whole product just before delivery? Of course not! So how do we solve this “Agilist’s Dilemma?” Rob Myers describes the two popular practices that can solve this dilemma: unit level test-driven development (TDD) and acceptance test-driven development (ATDD). Join Rob to explore the similarities and differences of these agile practices and learn how they support each other. Find out why ATDD is much more than traditional test-automation and how its practice drastically alters the role of the agile tester.

Register using the promo code SKES and save up to $300. Call the client support group at 888.268.8770 or register online at: https://www.sqe.com/STAREAST/Register/SelectConference.aspx

Better Software Conference & EXPO 2009
8-12 June 2009
Las Vegas, NV

Successful Teams Are TDD Teams
Thursday, June 11, 2009 12:45 p.m.

Test-Driven Development (TDD) is the practice of writing a test before writing code that implements the tested behavior, thus finding defects earlier. Rob Myers explains the two basic types of TDD: the original unit-level approach used mostly by developers, and the agile-inspired Acceptance-Test Driven Development (ATDD) which involves the entire team. Rob has experienced various difficulties in adopting TDD: developers who don’t spend a few extra moments to look for and clean up a new bit of code duplication; inexperienced coaches who confuse the developer-style TDD with the team ATDD; and waffling over the use of TDD, which limits its effectiveness. The resistance (overt or subtle) to these practices that can help developers’ succeed is deeply rooted in our brains and our cultures. Rob gives practical advice on overcoming that resistance and developing an “enjoyable development discipline” for a sustainable and practical TDD practice. With Rob’s practical advice, you may also discover how to lose weight and pay off your debts (seriously!). The success factors are identical.

Register using promo code SKBS and save up to $300. Call the client support group at 888.268.8770 or register online at: https://www.sqe.com/BetterSoftwareConf/Register/SelectConference.aspx

I hope to see you there!

Techniques for Agile Trainers

The following are skills/techniques/style tips that I sent out to a friend recently. I cc'ed some of my training mentors (Scott Bain of Net Objectives, and David Bernstein of Techniques of Design), and David suggested I blog this and get feedback/additions from other trainers (Agile or otherwise, really).

Originally I tried to categorize them, and the categories became a hindrance. So here they are in no particular order:

Projection: I had to learn to "project" my voice. To bellow out words without sounding like I'm yelling. It's like singing loudly in your car, but you have to do it when people are looking.

Immersion: The best courses (for everyone) are those where the instructor says less, and the attendees do more. Build creative exercises that give the attendees the chance to really build the right skills (while avoiding out-of-course-scope skills, e.g., don't ask testers to write code).

Diplomacy: This one is Scott's suggestion to me: If you get someone who wants to argue, give yourself the chance to really listen, and try to see how that person came to those conclusions, then make them right: "Yes, you could implement the pattern using a switch statement. And it would still be The Pattern! So, what do we gain and lose by using classes?"

Mimicry: Borrow techniques, phrases, and jokes from your favorite instructors. I can't teach just like Scott (I tried many years ago), but I do borrow from his style. I'm also still borrowing heavily from Fred George after 10 years, and two of my favorite college professors from 20 years ago.

Authority: You may want to tap your inner extrovert. Sometimes it feels like I'm wearing a mask, or playing a role, except that it's still me. I have to talk with authority, but avoid rambling excitedly about some fascinating (to me) detail that will lose people. Strangely, the "Helpful Guide" gets a far better reaction than the "Curious Scientist" persona. It's a shame, because I'm really the latter at heart. But I do let my inner geek out to play from time to time.

Honesty/Humility: No one appreciates a know-it-all. Allow yourself to say "I don't know. I'll see if I can find out for you before the end of class." (If you are worried about losing credibility, try "That's fascinating! I haven't run into that before. I'll definitely want to look into that and get back to you.") Or utilize the giant pool of knowledge sitting in the room: The attendees. I've taught some very bright developers, and they often know much more about the latest software tools. I couldn't possibly keep up with them all!

Also, allow yourself to make mistakes. Try not to point them out if it looks like they're trivial (like having two slides out of order, or Java code in a C# slide...), but if you misspeak, correct yourself.

Focus: Keep the course on-topic. If there are questions about another topic, offer to do a lunch-and-learn, or stay late, or come in early, to hold a brief talk about the other topic that's worrying them. Don't try to throw everything into a single course. It may be entertaining, but the necessary skills will be lost. It's also poor marketing, as they'll assume they don't need you back.

Pragmatism: Teach what you know, and what you believe in (or have seen work in the past), and continue to get real experience in what you teach (that's a tough one).

Others? (With thanks!)