Agile Testing with Lisa Crispin

On March 24, I facilitated a workshop at Agilistry Studios in Pleasanton, CA, on Learning for Testers. 19 practitioners from the Bay Area got together to consider how, as testers, we can learn ways to contribute more to our teams, as well as raising the bar for our profession. I’d like to share some of the ideas generated by this engaging group!

Why We Should Learn

We started out by considering good reasons that testers should learn. Participants self-organized into groups, brainstormed ideas, and each group chose their top three ideas to share. Some of the items surprised me. One reason to learn was “to reduce stress”. I asked the group to elaborate. They pointed out that it is stressful if you aren’t sure whether you have the appropriate skills to do your job. That is so true, I have felt that stress before!

Another category of reasons that resonated with me was “to have fun” and “not to be bored and have ADD”. Finding joy in our work should be our highest priority IMO!

Rather than take up room on this page, I invite you to see the photos of the actual results on my Picasa site.

What We Should Learn

I love the Bay Area, it is truly a crucible of software creativity. It is no surprise, therefore, that the ideas of what to learn were surprising to me.

“Knowing when to stop” – wow, so true. Any good tester can find things to test forever. When have we achieved the “minimum”? What is “enough”? Given that in real life, we have time and resource limitations, this is a crucial skill.

“How to invent test ideas” – cool!

“Deciding what is most important to test” – that kind of ties in with “Knowing when to stop”, I think. Knowing how to analyze risks, learning customer and user priorities, these are necessary skills for testers.

I was glad to see “thinking skills” were a priority, such as: Communication, Integrity, How to Teach. Integrity is particularly interesting to me. It’s essential, but how do we learn it? How do we teach it? Comments, please!

Another interesting skill to learn was the “Elevator Pitch”. If you can describe what you do in under a minute, you must really understand it. This exercise produced many intriguing skills – please check out the photos of the sticky notes.

How To Learn These Things?

I think the most innovative ideas in this workshop surfaced during the “How To” brainstorming.

Consider this: “Note your assumptions. Later, compare what happens to your assumptions. When you stop, note your reasons for stopping. Mindfulness.” I don’t know about you, but I am going to try this.

Journalism class, to learn how to make elevator pitches – what a great idea! We have to go outside our profession to get skills that will help us do our best work.

Risk taking – set out to fail! This takes a lot of courage, but failure is a great way to learn, so why not?

And finally, my favorite, “Learn by doing”. Isn’t that the best way? But to learn, we need time. If we’re always focused on meeting deadlines, we won’t absorb any learning.

Make some room today for learning. Your team has the best solutions to your problems. You just need to take the time to talk about them and think of small experiments (as Linda Rising says) to address them.

My colleague and co-author Janet Gregory and I have a new article in this month’s Better Software about Learning for Testers, with some additional material on Techwell.com. We’d love to know what you think, please comment!

Recently I tweeted about a fishbowl we conducted at the Business Analysis Workshop of the Better Software conference. Some tweeps weren’t familiar with the fishbowl format, so I thought I’d explain how I like to do fishbowls.

Fishbowl Discussion at BA Workshop, Better Software conference

Fishbowls are a good format for a panel discussion where you want to involve the whole audience, as well as a panel of pre-selected experts.

Put some chairs in the center of the room. They can face each other or, if the room isn’t set up for everyone to sit in a circle, face the audience. The number of chairs depends on the size of your audience. An average for a group of 20 people is five chairs. You’ll start with only four of the chairs occupied. Arrange the rest of the chairs in the room in a circle or semi-circle around the fishbowl.

If you have pre-selected panelists, have them sit down in the chairs leaving one chair empty. The rules are simple: anyone in the room can come sit in the empty chair. When that happens, someone else on the panel has to get up and return to the audience. Panelists may come and go by sitting in the empty chair whenever they want to join the debate.

The audience doesn’t participate actively in the discussion. You have to sit in the empty chair to start contributing to the discussion. The beauty of the fishbowl is that the audience gets to hear a variety of viewpoints, and anyone in the audience can choose to participate.

I’ve used fishbowls for panel discussions of controversial topics. Jean Tabaka recently facilitated a “Kanban vs. Scrum” fishbowl debate at Better Software, and allowed people to contribute via Twitter, as well. I’ve also used them for workshops where the participants are trying to come up with new ideas about a topic. For example, I might use a fishbowl format for a workshop where we try to think of better ways for development teams to elicit requirements from their customers. For my starting panel, I might choose people such as Elisabeth Hendrickson, Antony Marcano, Gojko Adzic and Jennitta Andrea, who are recognized experts in using customer-facing tests to drive development. They’re bound to have some good experiences to relate. But there’d also be a roomful of practitioners who have their own ideas and experiences, and with a fishbowl format, we get to hear from everyone.

Try a fishbowl at your next local user group meeting. It’s a great way for everyone to contribute, and it produces lots of valuable ideas from a variety of viewpoints.