Agile Testing with Lisa Crispin
Providing Practical Agile Testing Guidance

I enjoy listening to the “Testing in the Pub” podcasts with Stephen Janaway and Dan Ashby (along with various guests). Though the episodes make me thirsty for a pint of cider, the casual but insightful conversations inspire me to learn and try different ideas. One recent episode was about being a valued team member. I was struck by their observation that one needs confidence to be an effective communicator. If you are confident in your skills and experience, you can go talk to anyone on the team to ask questions, to raise and investigate issues.

That was a real aha moment for me. As testers we talk a lot about learning about our software to gain confidence in what we’re going to deliver. But I hadn’t thought about the value of being confident in yourself. Janet Gregory and I have been presenting conference sessions about whether a tester needs programming skills to be to be useful. Our view is that technical awareness helps testers communicate with programmers because it gives them a shared language. But after hearing the Testing in the Pub podcast, I think that learning some technical skills also builds confidence.

Looking back on my own career, I remember that when I faced a tough challenge, such as learning a new tool, I felt confident that somehow I would succeed. I started out as a programmer/analyst, and though it’s been a long time since I spent a significant amount of my time coding, I feel confident in conversations with programmers. I’ve learned a bunch of difficult domains, so I believe I can learn any new domain quickly. That makes me confident in approaching business experts and learning from them.

Janet and I have six confidence-building practices to succeed with agile testing (see below). What are the confidence-building practices to succeed in adding value as a tester? Just off the top of my head:

  • Make time to learn. Set goals, make a personal kanban board or other organizing tool so that you’ll work on them, use pomodoros or some similar technique to pace yourself.
  • Public speaking is scary, but builds confidence. Helping others learn means you learn too. Volunteer to share your unique experiences at a local meetup.
  • Put a bowl of chocolates on your worktop and invite teammates to come help themselves. It gives you a chance to chat informally and get to know them better.

What ideas do you have for building your own confidence as a tester and team member?

Confidence Building Practices for Agile Testing

This is the second of possibly a few posts about my “aha moments” at Agile Roots. In addition to pairing with Janet on two sessions (see previous post), I was lucky enough to pair with Amitai Schlair (see his awesome Agile in 3 Minutes podcasts) for a DevOps Dojo.

The code’s ready. Wait, what is this data?

We asked participants to pair up, with one person playing the role of Dev, the other Ops. Our “product” was a script to print labels (see GitHub for workshop material). We began with Devs throwing their code over the proverbial wall to Ops, who provided the production data. No surprise, addresses such as “Belling, Vicar of St Loony Up the Cream Bun and Jam,Arthur,Rev.,789 Incubator-Jones Crescent” tripped up our software.

After a retrospective, the Dev and Ops pairs worked together (hey, that was the conference theme!) to drive the scripting with tests involving the “prod” data.

Feeling their pain

In hindsight our exercises were a bit simplistic, but hey, we only had 90 minutes. More important to me was that we had real-life Operations people in our workshop! I was fascinated to hear their “war stories”. One pointed out that the last person to touch the code gets the blame when things go wrong. In my experience, sometimes this is Test – but of course, if Ops deploys the code to production, they get the blame first.

Experiments to try

Ideas for Dev-Ops Pairing

Ideas for Dev-Ops Pairing

In the last section of our workshop, we brainstormed on ways each participant could go back and foster dev – ops collaboration in their own organization. One interesting idea was “monitoring-driven development”. Ops can provide helpful production metrics as well as helpful tools. This can be effective for things like improving product performance.

One Ops person said he collaborates with Dev to do Operational Release Tests on an unused prod server before doing the official prod deploy. Making a plan for easy rollbacks seems obvious, but sometimes is neglected.

We talked about the need to support each other, and build trust across the organization. Even dipping your toe in the pairing water with 10 – 15 minute Dev-Ops pairing sessions can help.

Trust often simply has to be earned. If you can show how

More ideas

More ideas

your tests keep bad problems out of production, others will pay attention. A one-team approach helps build relationships and break the chain of blame.

The importance of empathy shouldn’t be a surprise, but I hadn’t thought about Dev – Ops collaboration so much in those terms until the Ops folks in our workshop told their stories. We need a mindset shift. A “Not my problem” attitude doesn’t build relationships.

Your experiments?

If you were in our workshop, I’d love to hear if you tried any of the ideas we discussed in the workshop. If you weren’t in our workshop, I would still love to hear about anything you’ve done to build those bridges between Dev and Ops.

It’s not news, but… why aren’t we all doing this already?

The lines between testers and programmers have blurred in recent years. So have the lines between operations and other roles on the software delivery team. We may be better off thinking in terms of competencies rather than roles. Working Together ™ to guide development with tests from the Ops perspective as well as that of testers and others is, to me, the obvious way to go.


I learned so much last week at Agile Roots 2015 last week. Check out the artifacts, they’ll inspire you too! Janet Gregory and I did a plenary talk on “Do Testers Have to Code… To Be Useful?” I always love pair presenting with Janet. She did a super job of explaining our views on the subject. To summarize: Your software delivery team already has coders, and they can write test code as well as production code. But we think testers do need technical awareness to help them communicate and collaborate well with other team members.

This blog post is meant to be about our workshop, though, so on to that. We had 90 minutes and a great group of participants to think about what skills a team needs to help them build quality in to their software product. Testing isn’t a phase, as our friend Elisabeth Hendrickson so aptly says. We know we can’t test quality into a product (I am not sure who first said that, but I’ve heard it for 20 years! Still, people seem to try!) Quality has to be baked in. What skills help us do that? As testers, Janet and I tend to focus on testing skills, but are they the most important?

T-Shaped Skills

Each of us has a wide range of thinking (aka ‘soft’ or ‘people’) and technical skills. Most of us also have some area of special passion where we have deep skills. For example, I have lots of experience in exploratory testing, test automation, eliciting examples from customers, SQL, and so on. But I can bring the most value to my team with my ability to learn domains quickly – that’s my deep skill. I learned about the T-Shaped Skills concept from Rob Lambert. Each workshop participant noted their skills which can help their team build in quality, one per sticky note.

Commitment to quality

Quality is like Mom and apple pie. Ask any software delivery team, they’ll say they want to create a high-quality product. But are they really committed to doing that? What will they do when they encounter an obstacle? We shared stories and discussed the importance of making that commitment mean something. It will take a variety of skills, experience and perspectives to creatively overcome all the things that get in the way of building in quality. Get your team together and talk about what your commitment to quality really mans.

Square-Shaped Teams

When all team members put their T-shaped skill sets together, we get square-shaped teams, see Adam Knight‘s blog post on this topic. Our workshop participants compared their individual skills, grouped similar ones, and discussed which were most important. (Pictures of the results are at the end of this post). What skills can each specialty bring to the party? If an essential skill is missing, how can your team obtain it?

Transferring knowledge, effecting change

We discussed collaboration techniques teams can use to make the best use of specialized skills they need. Learning new skills or sharing specialized ones can mean change, and change is hard. Patterns from More Fearless Change by Linda Rising and Mary Lynn Manns are helpful as you try to spread new ideas or encourage new experiments.

Each workshop group discussed the skill area they deemed most important, and thought of experiments they could try with their own teams to build those skills. Interestingly, communication skills, rather than technical testing skills such as exploratory testing or test automation, were tops in three out of the five table groups. The other two groups chose related skill areas: conflict resolution and gaining empathy with users. Interesting experiments were tried. One group decided to try teaching a simple skill to see how hard it might be. One of the group members was left handed, and set about teaching the others to write left-handed. This proved a simple way to learn how to teach a skill, a pre-requisite to helping spread skills across the team! Another group played an icebreaker game to learn more about each other as a first step in improving communication. Again, this is something simple and fun that any team can try.


With only 90 minutes for our workshop, we didn’t have time to try out a lot of techniques to transfer skills. For myself, a key giveaway (I learned that term from Alex Schwarz and Fanny Pittack at last year’s Agile Testing Days, I like it better than takeaways) were that what so many play down as “soft” skills form the core strength of a team’s ability to build quality into their software. If they can’t communicate with each other or their customer effectively, it’s hard even to define what quality means to them and to their customer. Another “aha” moment was realizing that extremely simple exercises such as an icebreaker game or teaching a skill like writing left-handed provide a lot of insights and help teams work together better.

Below are the skill charts from each of our groups (WP won’t let me format these in a nicer way, for some reason). You can also check out our slides, which have some good resources for further reading. Janet and I will do a similar workshop at Agile Testing Days, but we’ll have a whole day there, so we are looking forward to more in-depth outcomes which we can share.





I work every day as a tester on the Pivotal Tracker team. Some people think that because I’ve written books and speak at conferences I must be a full time consultant, but my passion lies in being a member of a great team and doing hands-on testing.


Brainstorming with JoEllen, at our old office

It’s easy for me to go around telling you all what’s the best way to build quality into a software product, but practicing what I preach can be a challenge. For example, I’m a very shy person with self-esteem issues. So though I’m always telling you how great pairing is, I often find it hard to leave my bubble and pair with amazing people like my teammate JoEllen Carter.

Here’s a slice of life from a particularly exciting week. We moved to a fancy new office half a block down the street, along with other teams from Pivotal Labs. Right now our Tracker team is rattling around in our new digs, but we have several new hires, interns and a Colorado School of Mines project team joining us soon.

Enough said

Enough said

Until all those new folks join us, there are extra monitors lying around. One of my teammates, knowing how much I love major monitor real estate, hooked a third monitor up to my usual workstation. Of course, another teammate caught me using my laptop for a standup meeting with some remote team members, and posted it on our Slack channel. Yeah, I look pretty silly! And there’s a downside: it’d be nice to move locations every day as our dev pairs do, but I can’t tear myself away from those three monitors. Well, it won’t last forever.

On the right are the scenarios I wrote, on the left are the designer's ideas.

On the right are the scenarios I wrote, on the left are the designer’s ideas.

Our new space has acres of glorious whiteboards. We had few whiteboards at the old office, but whenever any of us got in front of a whiteboard and started drawing while talking, magic happened. Today, a few of us started discussing a poor user experience in our customer signup process. After a few minutes of waving hands and explaining, I walked over to the giant wall o’ whiteboards and wrote out three scenarios. The others walked over and we had a good conversation.

Later on, the designer and a couple of developers went back to the whiteboard to talk more about it. The designer sketched out his ideas. Writing and drawing on the whiteboard helped us think things through and share the same understanding about the problem and the potential solution.


New Tracker office

Other stuff that went on this week? I usually work from home two days a week because I live 35 miles and much gridlock away from work. The office move translated into problems connecting with the office. The team is changing up how we do builds and deploys, and that’s getting in the way of delivering stories for final acceptance testing. We testers pitch in on customer support, and that’s been a bit busy this week. Like everyone I know, I don’t have enough time to do all the things I want/need to be doing. But we sure have a pretty new office!

Oh, and I did NOT pair with JoEllen at all. This is terrible. OK, she was gone the first two days of the week. We have a three day Hackathon next week. I had better take advantage of the opportunity.



Janet Gregory and I enjoyed participating in the Quality in Agile conference in Vancouver April 20-21. We paired on a keynote: “Do testers need to code… to be useful?” Our opinion in a nutshell: testers need technical awareness to collaborate effectively with all their team members, but our software delivery teams already should have expert coders!

Even if they don’t write code, testers need to participate in automating regression tests and other useful automation, in collaboration with programmers, business stakeholders and others. Janet and I facilitated an all-day workshop on advanced topics in agile testing, with a focus on automation.

Challenges around automation

After some introductory slides, the 15 workshop participants self-organized into three smaller groups, choosing to sit with people that had similar goals for the day, or who had experience related to their goals. Each person listed their team’s impediments to automation, one per sticky note, and we grouped these on a big wall chart.

Automation Challenges

Automation Challenges

Next, everyone dot voted on the topics they wanted to tackle during the workshop. The top three vote-getters were:

  • Culture and responsibility – whose job is it to automate?
  • Lack of time for automation activities
  • Things that make tests hard to automate, such as complexity

(Note, you can find higher resolution photos of all the session wall charts, including those not on this post.)

Formulating the problem and brainstorming ideas to overcome it

Mind map and problem statement for cultural challenges

Mind map and problem statement for cultural challenges

Each group was tasked with writing their own problem statement for the culture and responsibility topic. It is challenging to write a good problem statement! You can see an example at the bottom of the mind map at left. Once the problem was defined, everyone picked up a Sharpie and each team mind mapped on their big piece of easel pad paper. IMG_4427

One group focused on a lack of shared vision and investment in automation at the company level. Another saw a lack of education on both sides.

Third group's mind map is on the right - my individual pic of it was blurred

Third group’s mind map is on the right – my individual pic of it was blurred

I thought it was interesting that the third group exploring culture and responsibility mentioned doing social activities together, and honing soft and tech skills including being respectful of each other.

For topic #2, after each group wrote their problem statement around the lack of time for automation, we tried a different brainstorming technique: Brainwriting. Each person wrote their ideas for dealing with complexity and other things that make automation difficult on a plain piece of paper. Every three minutes, they passed their paper to the group member to their right. They read what was written already, then wrote more ideas. This continued until each person within the group had written on each paper. Most people agreed that reading other peoples’ ideas jogged new ones for themselves. This technique lets people who might not be comfortable coming forward to draw on a mind map or say their ideas aloud contribute equally.


Example problem statement


Ideas for dealing with a brittle app


Ideas for good code design and for collaboration

For topic #3 (sample problem statement to the left), we did “brainwriting with a twist”, an idea of Janet’s. Each team started by drawing, mindmapping or brainwriting ideas on a big flip chart page. After 10 minutes, each group moved to the next group’s flip chart, read the problem statement and ideas, and added their own. Some specific ways to design better automation code came out of this, as well as ideas for better tester-coder collaboration and ways to make these problems more visible.

Designing experiments

Example experiments

Example experiments

Screen Shot 2015-04-26 at 1.11.02 PMOf course, there is more to problem solving than brainstorming ideas. Janet presented a model of Esther Derby’s (left): define the problem and desired outcome, understand the context and requirements around potential solutions, design experiments, try them and evaluate the results. Each team spent time coming up with experiments they will try when back with their own teams. We hope that participants will report back to us on how their experiments went!

Got automation challenges – or any challenges related to quality and testing, for that matter? Get your team together, try out some brainstorming techniques, make it comfortable and safe for each person to contribute their ideas. Identify the biggest problem, brainstorm a couple of experiments to try to make that problem smaller, and use your retrospectives to evaluate the results. Keep experimenting, inspecting and adapting. Over time, your problems will be smaller and your successes bigger. But remember to celebrate even the small successes!

I learned a lot at Mile High Agile last Friday. Here are some notes from sessions I attended. I never heard the for-sure count of attendees, for sure it was well over 700 people. The fun part was running into people I worked with 15, 20 or more years ago, I think pretty much the whole tech population of the Front Range was there.

Mike Cohn, keynote, “Let Go of Knowing: How holding on to your views may hold you back”.

I expected magnificence from Mike and I wasn’t disappointed! (I worked for Mike back in 2003-4 and have learned so much from him over the years. Plus, the books I’ve co-written with Janet Gregory are part of Mike’s Signature Series of books with Addison Wesley.)

It’s hard to sum Mike’s talk up briefly. One theme was “intellectual humility“, being able to say, “I think this is the best way to do X, but I could be wrong”. He talked about the Dunning-Kruger effect – the less we know, the less we think there is to know.” Lots of interesting studies around that which are worth looking up.

Mike pointed out that process != a list of rules, and encouraged everyone to avoid “brand loyalty”. Don’t go only for one “brand” of agile – Mike pointed out that though Scrum is his bread and butter, he is known for user stories and estimates, which both came from XP. Question assumptions, lose your grip on certainty. Too many of us aren’t as open-minded as we should be. When we’re willing to be wrong, we have a new path to growth.

Mike Clement, “The Quest for Continuous Delivery at PluralSight”

  • One of Mike’s main messages was that the whole project team needs to get involved in CD. Most of this wasn’t new to me: “you should be able to push a button and have confidence, get ideas to market quickly” – amen. “Source code control for ALL THE THINGS”.
  • Mike’s team strongly favors feature toggles over feature branches so that they’re integrating continually. They can conveniently toggle off in prod if there are problems, instead of rolling back.
  • They use TeamCity for CI and seem to like it.
  • They’ve ben using a homegrown deployment tool. Mike strongly advises against this. They’re switching to Octopus (they are a .Net shop).
  • They use alerts in New Relic. They’ve been able to get better monitoring and live testing with New Relic (my team does this too).
  • They embrace DevOps as a culture, not a role, tho their Ops team is separate from their Dev teams.
  • He likes saltstack for server management, they treat server management as code.
  • They use Cassandra database scheme to automate modifications.
  • Their staging environment is not enough like prod and they’re working on that.
  • The goal is immutable infrastructure and continuous deployment – they aren’t there yet but still working towards it.

Mike wrapped up with a picture of Picasso’s Don Quixote and quoted the lyrics of “the Impossible Dream” which seemed appropriate for our quest for CD! But hey, we just need donkeys, right?

Paul Rayner, “Lean UX: Want to get better at the Lean discipline of ‘Deliver Faster’?

Paul highly recommends Jeff Gothelf’s book and video course on LeanUX. Check out his review of the book.

  • agile + design thinking + Lean startup = Lean UX
  • “requirements don’t exist. What you really have are unvalidated assumptions”. Question what’s in your backlog. Ask why.
  • UX design is a call to action on the part of the user, for example, “next step”.
  • Use a MVP to validate learning. Five properties of MVP:
    • Clear and concise
    • Prioritize ruthlessly
    • Stay agile – if it’s not what you need, fix it. Inspect and adapt.
    • Measure behavior – a lot of people don’t do this.
    • Use a call-to-action. Just give user one thing to click on.

Chris Shinkle, “You Can’t Manage What You Can’t See”

Visuals let you communicate a lot of information quickly. Chris had pictures of how they manage all the jets and traffic on a huge aircraft carrier – on a big table with little models of all the planes and equipment that the person in charge moves around manually. It was pretty impressive. Here are some more points I noted:

  • Make sure everyone’s looking at the same information. Visuals lead to better decision making, shared understanding (he quoted Jeff Patton’s book that we just read in our book club).
  • Chris advocated simple, low overhead visuals, making progress visible to all, identifying impediments to progress.
  • His teams use a combination (physical) Kanban and Scrum board, it was pretty interesting. They don’t just have cards on the boards, also lots of pictures and drawings. They use little tricks such as a story card turned sideways to remind them to talk about it in the standup. He feels physical boards and other visuals help people feel connected.
  • Remote people have a “sticky buddy” in the office to move their cards/stickies for them. They try to get things out of computers and up on walls.
  • They do use electronic boards as well, for history and analytics. He said people grumble about keeping both a physical and online board up to date, but in truth it isn’t a big amount of time.
  • He recommended something by Arne Roock but I’m not sure if it was his book or what.

My own workshop, “Building Your Agile Testing Skill Sets”

I had a lot of people in my own workshop, “Build your agile testing skill sets“, and a good diversity of roles, about a third testers, a third developers, and the rest BAs, managers, ScrumMasters and the like.

I guess it was around 60 people. It was mostly group exercises, each group brainstorming about what skills testers need and teams need to succeed with testing, what specific skills their own teams are missing, and ideas for experiments to obtain the missing skills.

I was surprised that overall, the knowledge of testing was lower than I expected. There were some highly experienced expert practitioners, but many people seemed to be beginners at both testing and agile. A lot of people were in companies who have silo’ed “QA teams” and where testers were considered “second class citizens”.

Everyone seemed to enjoy the discussions and sharing of lots of interesting ideas. I hope they each got a couple of ideas to try for baby steps towards doing a better job of building quality in.

Bernice Niel Ruhland, a director of quality management programs, contributed so much value to  More Agile Testing. In addition to sidebars where she explains ideas she uses for training and managing testers, we refer to several stories and ideas we learned from her. She also read every draft of every chapter at least three times and gave us invaluable feedback to help create the final book.

Janet Gregory and I are so excited that Bernice has shared her experiences as a More Agile Testing reviewer and contributor. I hope it will inspire you to write about your own experiences, volunteer to review your colleagues’ draft publications, and perhaps read our book!

And while you are there, keep on reading. Bernice blogs regularly and I’ve learned so much from her stories. For example, I love her tribute to Leonard Nimoy and her stories of how he influenced her career.

Bernice’s creativity extends beyond her testing career to other pursuits, one of which is cuisine. She has a wonderful cooking blog, Realistic Cooking Ideas. This has inspired so many wonderful meals at my house! Don’t read it, though if you are hungry!

Thanks so much to Bernice!

Pairing FTW

Pairing FTW!

This post benefits from a bit of context: my day job is as a tester on the Pivotal Tracker team. Tracker is a project tracking tool with an awesome API. Our API doc is awesome too. It’s full of examples which are generated from the automated regression tests that run in our CI, so they are always accurate and up to date.

Oh, and part of my day job is to do customer support for Tracker. We often hear from users who would like to get a report of cycle time for their project’s stories. Cycle time is a great metric. The way I like to look at it is, when did you actively start working on a story, and when did that story finally get accepted? Unfortunately, this information isn’t easily visible in our tool. It’s not hard to obtain it via our API, but, the best way to get it is not immediately obvious either.

For a couple of years, I have wished I had an example script using our API to compute cycle time for stories that we could give customers. Sadly, I’ve had to let my Ruby skills rust away, because at work I don’t get to automate regression tests (the programmers do all that), and I spent most of the past couple of years co-writing a book.

Recently, our team had three “hack days” to do whatever we chose. One of the activities I planned was to work on this example cycle time script. My soon-to-be-erstwhile teammate Glen Ivey quickly wrote up an example script for me. But my own feeble efforts to enhance it were futile. Unfortunately, all my teammates were engaged in their own special hack days projects.

I whinged about this on Twitter, and Amitai Schlair, whom I only knew from Twitter, offered to pair with me. This was good and bad. One the one hand, awesome to have someone to pair with me! OTOH, gosh I’m terrible at Ruby now, how embarrassing to pair with anyone! I started thinking of excuses NOT to do it. However, Amitai was so kind, I faced my fear. We paired.

First we had to figure out how to communicate and screenshare. We ended up with Skype and Screenhero. Amitai introduced me to a great concept: first, write what I want to do in psuedocode. Then turn each line of that into a method. Then, start fleshing out those methods with real code. Amitai’s instinct was to do this TDD. But due to time limitations, our approach was: write a line of code, then run the script to see what it does. We worked step by step. By the end of our session (which was no more than a couple of hours), we had gotten as far as showing the last state change for each of the stories that were pertinent to the report.

After competing priorities led us to stop our session, I identified an issue with our new code. A teammate paired with me to show me a way to debug it and we were able to fix it. The script still wasn’t finished. Luckily, my soon-to-be-erstwhile teammate Glen later paired with me to get the script to a point where it produces a report of cycle times for the most recently accepted 500 stories.

The script runs way too slow, and Glen has explained to me a better approach. I await another pairing opportunity to do this. So what’s the takeaway for you, the reader?

Pairing is hard. You fear exposing your weaknesses to another human being. You feel pressure to keep up your side. But that’s only before you actually start pairing. The truth is we all want each other to succeed. Your friends and teammates aren’t out to make you feel stupid. And pairing is so powerful. It gets you over that “hump” of fear. Two heads really are better than one.

Is there something you’d like to try, but you feel you don’t know enough? Find a pair, and go for it!




I just received a flyer in my snail mail for yet another conference where four out of the five keynote speakers are white men and only one is a woman. Are you kidding me? And this is a testing conference. Testing is a field that does indeed have lots of women, I would guess a significantly higher percentage than, say, programming.

I know the organizers of this conference and they are good people who aren’t purposely discriminating against women (or minorities, for that matter). But they aren’t trying hard enough, either. I’ve personally sent long lists of women I recommend to speak at their conferences. True, most of these women aren’t “known” keynote speakers – maybe because nobody ever asks them to keynote. These women are highly experienced testing practitioners who have valuable experience to share.

This same company has an upcoming testing conference with no female keynoters, so I guess this is an improvement. But I’m not letting them off the hook, and you shouldn’t either.

What do you value more: a highly entertaining, “big name” keynote speech? Or an experienced practitioner who competently helps you learn some new ideas to go and try with your own teams, but maybe isn’t as well known or flashy?

You probably don’t get to go to many conferences, so be choosy. Choose the ones with a diverse lineup of not only keynoters but presenters of all types of sessions. In fact, choose conferences that have lots of hands-on sessions where you get to learn by practicing with your peers. We have the choice of these conferences now. And I hope you will leave your favorites in comments here. I don’t want to make my friends unhappy by naming names here, but email me and I’ll give you my own recommendations. (Another disclaimer – I’m personally not looking for keynoting gigs, so these are not sour grapes. I don’t like doing keynotes, and I know my limitations as a presenter).

The organizations sponsoring and organizing conferences are pandering to what they think you, their paying audience, wants to see. If you’re going to conferences to see big names and polished speakers, and you don’t care if the lineup is diverse, go ahead. If you want a really great learning experience, maybe do some more research about where your time and money will reap the most value for you.

I’m not trying to start a boycott, but I am saying: we are the market. Let’s start demanding what we want, and I know these conference organizers will then have to step up and try harder.

Since publishing More Agile Testing with Janet Gregory, I’ve enjoyed time for writing new articles and participating in interviews. Please see my Articles page for links to these. I’d love to hear your feedback on any of these. Have you tried any of the practices or ideas discussed in the articles or interviews?