This is a guest post by Johanna Rothman
Your agile team might think that the developers collaborate with developers and testers collaborate with testers. However, the more the various people collaborate across specialty, the better the product can be. And, they might be able to finish the work faster.
Amy, a tester, often ate lunch with the rest of her test team. The developers often ate a different table. Today, she happened to overhear a conversation between two developers, David and John, talking about testing for performance. They seemed to be stuck.
She turned around and said, “I just wrote some tests in that area last week. Want to see them?”
David looked down at his food. Well, she knew David was really shy.
John said, “Sure. Send them to me?”
“You bet,” Amy said. “As soon as I’m done with lunch.” She turned back to the rest of the testers and finished lunch.
When she returned to her office, she sent both David and John a link to the tests she’d created last week.
In about an hour, she got a message from David. It said, “Fist-pump! You really helped us. Thank you!”
An exclamation mark from a guy who barely spoke? Must be a red-letter day.
A couple of weeks later, Amy discussed one of her testing challenges at lunch. She felt a tap on her shoulder.
David said, “I think I know what you could do.” He didn’t look at her, but at least he was talking.
“Would you like me to stop by after lunch and we can discuss it?” Amy asked.
“Sure,” he said.
After lunch, Amy stopped by his office. They discussed her concerns at length and drew some diagrams on the whiteboard. Then he asked, “Is it okay if I code a little to try this one out?”
“Sure,” she said. “As long as I get to code the next one.”
The two of them spent about an hour creating small test experiments. They traded off who would create the tests. At the end of that time, Amy knew what she needed to do. And, David realized where he could change the code to make it easier to test.
This wasn’t a traditional pairing with a driver and a navigator. However, it was a form of pairing that worked for them. When they paired, both Amy and David learned more than they could separately.
Pairing Works Across Specialty
Even in supposedly agile teams, I often see the developers and testers work separately. The developers might pair with each other. The testers might pair with each other. But I often see even better results when people pair across specialty.
Those specialties don’t have to be just developer-tester. The specialties might be tester/database expert or tester/user-interface expert.
When testers partner with the database expert, the expert often learns how to make the database internals more testable. And, the tester might learn tips and tricks to make the testing easier and faster.
At one company, the testers each spent close to an hour regenerating a particular database from scratch every time they wanted to test. When the DBA saw what they were doing, he explained how to regenerate the database they wanted in just five minutes. The testers were thrilled. And, even though he didn’t like the fact that they found problems in the database, he was glad they could test his changes much faster.
At another company, the user interface expert, Al, kept designing a screen that Bob, the tester, found impossible to use.
Bob asked, “You know, I keep fighting this screen. How about I show you my disconnect?”
Al agreed and sat with Bob. The two of them explained their perspectives to each other. Once Al realized the problems, he changed the screen.
Pairing is great. Mobbing can be even better.
Mobbing Helps the Entire Team Learn
When teams mob, they all work together on the same problem. In general, a mob has one typist, the person at the keyboard. They might have guidelines on a primary navigator, or if everyone is allowed to talk to the typist at once. (I don’t recommend everyone talking at once unless the team decides to discuss the work in progress.)
You don’t have to be an agile team to mob. All you need is the willingness to work together to solve a single problem.
Amy, David, and John were part of a team that called itself an agile team. However, the team members didn’t often collaborate on the work together. Because the team members didn’t collaborate, their work took “too long” in terms of feedback loops.
The people on that team separated at lunch to eat with their functional groups. Their lunches became informal Communities of Practice. However, they didn’t gain the value of hashing out problems together, as a team.
Amy and David reported back to their team about how their pair code-and-test experiments had gone. David said, “I’m not a big fan of talking. But, this worked really well. I’d like to try mobbing on some of our more difficult problems.”
The rest of the team was surprised but willing to try it. They commandeered a conference room so they would have a big screen.
They agreed that one person, the navigator would explain what the rest of the team wanted the typist to do. They even agree to change roles every five minutes. And, they agreed that each person would work according to his or her specialty when she or he was the navigator.
They chose a feature that they thought was going to take close to a week to implement. At first, it seemed as if they couldn’t agree on anything. That’s when David said, “Let’s frame this as a series of experiments. What’s the list of experiments we want to do?”
The team listed 18 experiments. Now, they had a bit of a plan: Code and test each experiment.
Partway through, one of the developers suggested they consider test-driven-development as a way to drive their thinking. They experimented with that. Half the team liked it and half the team hated it. They decided to continue with their previous way of working.
At the end of the day, they had narrowed the problem to two alternatives from their original list of 18. They agreed to continue the next day to see what they could do as a team.
When they all arrived the next day, they spent the morning and finished the feature. All the code, all the tests, even the necessary release notes. They decided to mob every time they had a feature that they thought would take more than three days.
But the best part was what people learned. The developers learned the kinds of hooks the testers needed before the developers wrote the code. The testers learned how the developers would like the data. Not bug reports, but how to organize the data from the tests.
Everyone learned a lot more about the inside of the product, and how to simplify the development and the testing.
Team Collaboration Works
The more the team works as a team—collaborating across specialty—the easier it is to finish the work. In addition, everyone learns more than they expected.
If you’re not collaborating yet across specialties, especially as a tester with your developers, consider it. And, consider how your team might mob or otherwise collaborate together.
The more you work together as a team, the faster and easier the work will be.
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Johanna is the author of fourteen books and hundreds of articles. Find the Pragmatic Manager, a monthly email newsletter, and her blogs at jrothman.com and createadaptablelife.com.
