Agile Testing with Lisa Crispin

I’ve been writing a lot on SearchSoftwareQuality and Techwell (aka Stickyminds) lately, no time to blog. I have lots to say so I hope I have blogging time soon! I’ll start by reporting back from Belgium Testing Days.

There is so much goodness to report from last week’s Belgium Testing Days! I’ll be writing all that up, but I wanted to start with the great ideas that came out of my session on “Speaking their language: What testers can learn to work more effectively with programmers”. My slide deck will give you a bit of a feel for the talk, but as I’m going with simpler slides these days, you had to be there to know what I said. However, much more interesting are the ideas generated by the participants, who divided into small groups and made lists of what testers should learn to help them communicate and collaborate better with programmers. I asked them to go beyond the ideas I described in my talk. Each group gave their top choices, and I wrote them on a flip chart.

The last group to go had the one we all agreed was most important – have fun!

The first day of Agile Coach Camp began with each person introducing him- or herself and his-or-her superpower. There were some clever ones. I said mine was getting people to write on the whiteboard, because whenever I do, magic happens, but then Tim Ottinger tweeted his disappointment that my superpower didn’t involve donkeys.

The first open space session I attended was on Systems Thinking, facilitated by Ken Furlong. I didn’t understand a lot of this, and there were some skeery formulas, but some folks tweeted some links to me to learn more about it.

Net-Maps

Net mapping is my biggest takeaway from ACCUS so far. Eva Schiffer, whose background is in things like working with GMOs in Ghana and not IT, created net mapping to identify different people or organizations that influence a project. You identify the players: people, departments, groups. You draw connections with color-coding between them, for example, hierarchies, funding, conflicts, adversaries, being in it together. People can do the maps together.

Stacks of checker-like objects piled on each influencer denote the amount of influence. This is a great visual. If you’re doing this with a group, rather than denote “positive” and “negative” influences, you could choose two more neutral goals, such as “stability” and “change”, so that people feel safe. Eva noted that the “average view” of who influences what doesn’t do anything for you, you have to let each person explain their viewpoint.

I’m such a fan of mind mapping, and this seems to take it to another level. I am eager to try this.

One of the participants, who is from the education profession (not IT), suggested it would work well for kids, for things like exploring peer pressure. It was so interesting to get perspectives from people outside of IT, both leading and participating in ACCUS sessions.

More than Agile

George Dinwiddie facilitated this session on what agile coaches need to know besides agile. Many skills we talked about were what Isabel Evans calls “thinking skills”, other people call them “soft skills”: facilitation, creating space for the development team, PR, team dynamics, teaching people outside the team to support the team rather than trying to “drive”. We talked about ways to help teams learn to self-0rganize: providing gentle direction, helping form the team, helping them take on achievable challenges. One tweetable quote from this session was “Trust goes in, pride goes out”.

I was lucky that our team had Mike Cohn for our manager/coach for the first year of our agile transition. First he helped us decide on our commitment to quality. We committed to delivering the best quality software that we possibly could. Mike helped us make this commitment mean something. He exhorted us every day to write code that we’d be proud to take home and show our moms. He told us over and over, “I don’t care how much you get done, or whether you meet some deadline. I only care that you produce the best quality that you can.” It took a long time for the team to trust this message, but once we did, we invested a lot of time to learning valuable practices such as test-driven development and specification by example. This investment paid off in the ensuing years, as we built up a good base of re-usable code and test code. We have always kept our technical debt at a manageable level, and as a result we have a good steady velocity.

QWAN: Providing basic agile knowledge online, for free

Olaf Lewitz explained the idea of a free interactive course to teach agile basics, called QWAN (Quality Without a Name). This effort was partly inspired by the Kahn Academy. We brainstormed the what, how and why of this community effort, and came up with both ideas and questions. Check out the photo.

It’s lunchtime at ACCUS Games Day. Tobias Mayer warmed us up with some exercises that involved the whole group (60 – 70 people!) One was doing a “failure bow”, similar to the Language Hunters “How Fascinating!” If you feel you failed, raise your hands in a victory pose and shout out something happy. We will be doing this all weekend, I am sure!

One interesting insight came from comments on the enemy-shield/friend game. Often, a ScrumMaster or manager feels their role is to “protect” the team. Tobias noted that we are all adults and can protect ourselves. That made me think. I think our manager sometimes tries to protect us from the bureaucracy and silliness of our new parent company, with the best intentions, but I think sometimes that backfires. For example, if a manager proposes some half-arsed technical implementation for something the parent company wants, thinking it will reduce pressure on us and save us time, that isn’t really helping us. Better to let us be told directly about the business problem to be solved, then let us find the right way to solve it.

I tweeted that quote (really a paraphrase), and several people disagreed, saying that development teams may need protection from undue outside or management pressures. That’s valid. When my team first transitioned to agile, our manager convinced the business executives to let us have all the time we needed to learn good ways to develop software. Practices such as TDD are hard, and if you’re pressured to deliver, you won’t take the time needed to master them. If you’re punished for failures, you won’t experiment. So there is definitely a place for some protection of the team. Conversely, nobody should inhibit good communication between the development team and the customer team.

Coaching Skills Dojo

There were five track sessions to choose from after the warm-up, and it was hard to choose, but I went with Michael Sahota’s coaching skills dojo. This was a great chance to practice coaching, and learn by observing others and by playing the role of the client.

We started out by identifying observation, listening and questioning skills that coaches need. Then we took turns playing client, coach and observer. When playing client, we used real problems that we have. We had 20 minute sessions with five minutes for each ‘turn’, then five minutes of debrief.

Andrew Fuqua writing our ideas on observation, listening and questioning skills in Michael Sohata's coaching skills dojo

I feel my coaching skills are lacking, so I was fearful of this, but knowing I could use the “failure bow” gave me courage to take risks. It is so interesting to ask good questions, use appropriate body language, listen and observe well to help a client understand his problem and think of possible experiments to solve it. I have takeaways both in terms of coaching skills – I shouldn’t be afraid, I do have the skills, I need to remember and listen more, and help the client clarify the problem – and on what I learned from being coached on actual problems!

This afternoon, there are three timeslots, each has five sessions. So many choices, so little time! I’m looking forward to learning some new games, honing my coaching skills, and also getting help developing my own game to help testers and developers learn to communicate and collaborate better.

If you think conferences aimed at programmers are only for them, think again. I wrote about my experiences at ACCU 2011 on TechTarget. Take a chance and try a conference that doesn’t seem tailor-made for you!

I’m grateful to the Software Testing Club for asking me to report my experiences at StarEast. It was fun to do and will help me remember what I learned and what I want to try now as a result!

I wrote up my experiences at the excellent Belgium Testing Days conference which took place in February. In particular, I thought about what is different for me at conferences outside the U.S. compared with “domestic” conferences. They’re all great learning and networking opportunities, but culture makes for some nice differences. Overall it was a wonderful time and I’m still thinking how to apply everything I learned. Read about it on SearchSoftwareQuality.

I’m presenting in a virtual multi-media seminar sponsored by SearchSoftwareQuality on Dec.14: Agile in Action: Extending Agile Approaches in Testing, Development and Application Lifecycle Management. I’ll be talking about challenges faced by agile teams that are not co-located. This event is free, though you have to register. David West and Nari Kannan are also presenting.

I was so pleased when my copy of Naomi Karten’s Presentation Skills for Technical Professionals arrived the day before I left for Agile Testing Days in Berlin. I started presenting at conferences in the late 80s, and have presented at many conferences in this millenium. I’ve worked hard to improve as a speaker, facilitator and coach, I’ve taken lots of public speaking and presenting classes, I study the evaluations from each session’s participants, I read blog posts about how to present. But behind my conference persona, I am an extremely shy person, so it’s always a fight.

I read Naomi’s book on the flight to Berlin. It’s an easy and entertaining read, and I learned a lot. One gem was the advice to pause occasionally – when finishing a key point, when inviting questions, before advancing to the next slide. It gives participants time to let the information sink in, and to formulate questions. I talk WAY too fast, so this was a good tip for me. I remembered many times during my Agile Testing Days tutorial and keynote to pause for a moment, and that helped me remember to speak more slowly and clearly. (I still got evaluations that said I was hard to understand, but I hope I was better than in the past).

Another important takeaway was to set up ground rules at the beginning of the session. I always do this, but I liked the suggestion for managing time, to say to the group, “If we’re running short on time, would it be alright if I discontinue some discussions in the interest of moving on?” By framing a ground rule as a question, you get buy-in from the group.

Building rapport with the audience before the session starts was another good tip. I’ve done this in the past, but because I am such an introvert, I didn’t do it enough. I made a conscious effort in Berlin to engage individuals who arrived early and ask about their experiences on the topic I was about to present. When I got nervous later, I could look at the people I’d talked to ahead of time and felt I was in the company of friendly people.

The chapters on logistical preparations and the “presenter survival kit” contained many good reminders of things I know, but sometimes get sloppy about. For example, I had gotten out of the habit of putting my slides on a USB flash drive, in the event my MacBook dies and I have to borrow a laptop. I always think “I can download it if I need it”, but many conference rooms don’t have internet connectivity.

I think I’m good about avoiding PowerPoint abuse – my slides aren’t flashy, but they are also not overcrowded with information, and I don’t read them – but the chapter on using (and not mis-using) Powerpoint has good pointers (no pun intended). I also tell a lot of stories, so I was glad to read that Naomi recommends this practice and explains how to craft a story.

There is lots more great information about all aspects of presenting in this book. I highly recommend it to everyone who ever has to make a presentation – whether you only rarely have to present to fellow employees, or speak frequently at conferences. It has good reminders for experienced speakers, plus some nuggets you might not have thought of. If you’re new to presenting or nervous about it, following the instructions in this book will give you much more confidence and let you enjoy the experience instead of dreading it.

My Agile Testing Days tutorial is almost full, so my motivation here is not to advertise it, but to invite you to meet one of my donkeys, Ernest. I tried to make the video with both Ernest and Chester, but it was very windy outdoors that day and Chester was fidgety, we couldn’t get a good video. My friend Anna suggested taking Ernest indoors to do the video, so we went in the living room and it worked just fine. It’s short, please enjoy!

I have LOTS to write about StarEast, but I’d like to start with the conference-within-a-conference that a group of us planned on our own. Well, I didn’t do much planning, but Matt Heusser took the lead and lots of other folks including Justin Hunter planned a couple of fun and enlightening events.

We were self-titled the “Rebel Alliance”. I don’t think we were rebelling against anything, there are just a lot of Star Wars fans in the group. (Though there was a good lightning talk suggesting good things we do rebel against). I was going to be a Bantha until someone reminded me of a gruesome scene involving one.

But I digress. We had dinner one evening, at which we even got t-shirts with a star fighter on it. So much fun to get to know people such as Yvette Francino, Shmuel Gershon, Lanette Creamer, Selena Delisie to name just a few (and how great to have lots of women!) I’ve known Adam Goucher awhile and met him at Agile 2009 (if not before), but it was great to see him and his fellow editor of Beautiful Testing, Tim Riley (who did a great keynote at the conference).

Shmuel Gershon's lightning talk

The next evening our group had our own lightning talks, which were as intriguing and creative (maybe more) than anything at the conference. Adam talked about pirates, and Lanette talked about herding cats. This photo of Shmuel presenting a new session testing tool he wrote shows how much energy the speakers had.

Jon Bach had surprising and thought-provoking exercises, as always. These are just a few examples.

At the Rebel Alliance Lightning Talks

Selena and Dan took lots of videos, I hope those will show up someplace. David Gilbert provided his own tasty home brew – what a treat! He did a good talk too, on what we’re rebelling against, and for – learning vs. pass/fail, programmer’s best pal vs. quality police.

Conferences always get my brain buzzing, just being around such smart and creative testing professionals. But being a part of this terrific group was amazing. From old friends like Janet Gregory to more recent friends such as Sean Stolberg and Dawn Cannan, to people I only knew on Twitter up to now, such as Alex Kell, to people I didn’t know at all before, like Mark Vasco -  it was almost overwhelming! I wanted to talk to everyone at once!

After this experience, I suggest you consider this at your next conference: get a group of like-minded people together and plan an evening ahead of time. You’ll look forward to the conference that much more, and take exponentially more ideas home with you. And you’ll be part of a small community that hopefully will live on past the conference.