What can testers and developers learn from each other?

At Agile 2019, Bill Wake and I paired on a workshop on the Culture and Collaboration track at Agile 2019, “What testers and developers can learn from each other”. I was thrilled to be co-facilitating this with Bill, who was one of my early Extreme Programming heroes.

Doing a true workshop in a 75 minute time slot is a big challenge. You really need 90 minutes. Our participants were good sports, and they were energized and ready to go.

It occurs to me now that this is something we can all do within our own teams! Why not get everyone together and brainstorm what skills and knowledge are valuable to transfer to each other? We used a simple format and I think it’s worth trying other places!

Our goal

We explained the goal of our workshop in the abstract for our proposal to Agile 2019:

Have you ever said…?
“I wish those ____ understood ___”
“I wish those ___ would teach me about ___”

Our goal was to help testers and developers (and others) collaborate ore effectively. This could apply more widely. What can operations specialists help development specialists learn, and vice versa? What can database experts help other team members learn? We need for the whole team to collaborate to deliver valuable products to customers. We can do that more effectively when we understand each others’ challenges and have a wider range of skills to apply.

Setting up

Before the workshop, we flagged (literally, with colored flags, but you could use colored tablecloths or anything else distinguishing) some tables as “developers” and some as “testers”. As people came in, we asked them to choose a colored index card to show how they identified themselves. Blue if they were a coder/developer, green for a tester, and yellow for other roles. Unfortunately, our session was in a giant ballroom with tables set up for 10 people each. If we had had more time, we would have made the groups smaller;. Alas, our participants self-organized into fpur tables and we didn’t have time to reorganize them. If you try this, try to keep your groups to six or fewer people each.

Our setup got disorganized because we had projector issues and we couldn’t get the instructions up on screen. Plus we were running around trying to find the A/V experts.

Starting the workshop

Our volunteers did their best to compensate for the initial lack of slides. As people came in and chose their index card color, they were instructed to pick the table they identified with most strongly. Many of the the people with yellow cards had experience as a programmer or tester,

When we started, we introduced the workshop agenda. The tables populated by self-identified developers or programmers would come up with ideas for what developers could help testers learn so that they could collaborate more effectively. The tables with testers would think about what they could help developers learn about testing and building quality in. We asked people to loo look around their group and consider the amount of diversity.

Brainstorming ideas

The groups spent time brainstorming ideas for what they could help people in the “other” role learn. Group members wrote out their ideas, one idea per sticky note. They grouped similar ideas. We gave them more time to choose a topic and come up with ways to help people learn about that topic. They were tasked with creating a poster with their ideas including why that topic would be great to learn, what to watch out for, where to find resources to learn about it, and more.

Getting and using feedback

Next, we paired tables up – ideally, a “tester” and “developer” table in a pair. We asked one person from each table to take their poster to the other table, explain it, and get that table’s ideas. Then, each group could update or re-create their poster, incorporating the feedback from their pair group.As these activities went on, we were happy with the buzzing energy in the room!

Outcomes

Finally, we had each group present their poster. If we’d had more time, we’d have asked people to vote on their favorites, and share what ideas they’d take back and try with their own teams.

Here are photos of the posters. My personal favorite was the “House of Quality” from a group which, while brainstorming ideas for what to help developers learn, realized their ideas all related to the team, “how can we work better together”. The group member who explained it saved the best for last: The foundation of the house consisted of drawings of the team members. “Because the people on our team are the foundation”. Yes!

We had hoped to get some new ideas to share with the community. I think the most important idea we have to share is that these are conversations we need to have. While everyone on an agile team should be willing to help out with any activity involved with building, deploying and nurturing software, we all have specialized skills we can transfer to each other. This will help us work together more effectively, just as the House of Quality says.