This is a guest posting by Carol Brands.
One of the goals we had for our test team this year was moving the entire team into the development team room. Our experience with sitting one tester with the development team was a success, and we wanted to build on that by bringing in the others.
On the surface, this seemed like primarily a logistical problem, because the space in the team room is limited. We decided to start by adding one more tester to the team room so that two of our three testers would be sitting with development. We needed to get a new desk and add it to a space that already seemed full. Finding the right configuration took time, but we did it.
However, once the new desk was added, it became apparent that we had other issues. Two of our testers could now join the team room, but instead, both desks sat empty. What happened?
Get TestRail FREE for 30 days!
Leaving the Cubicles
It turns out the problem with having more testers in the team room wasn’t a matter of logistics. It was a matter of psychology. Our test team are all introverts, and we have a strong natural preference for keeping to ourselves and working quietly within the confines of the test team room’s cubicles.
Last year, I was the first tester to begin sitting in the development team room. It took a long time to warm up to the idea. The development team room is an open office, with no barriers between you and the other team members. Everybody has their own desk, but that is the only physical designation of personal space.
It was uncomfortable at first. I strongly prefer hiding in my cubicle to being exposed to a room full of social engagement. But I knew that the communication happening in that room was important to my work, so I made the transition. I started with half-days and worked my way up over two months to sitting in the development team room on a full-time basis.
When we added the second desk to the development team room, I decided to sit in the test team room again. Because there were only two new desks in the development team room, I wanted to make sure the other two testers had the same opportunity I did to slowly make the transition and build a relationship with the developers the way I had. My worry was that if I was sitting at one of those desks, I was taking away the opportunity from someone else.
But this was a mistake. What happened instead was that if I didn’t sit in the development room, no one did. The other testers were uncomfortable with the idea of sitting in that open, less quiet space. After talking to them, I learned that the thinking had become, “If no one else has to sit there, I shouldn’t have to, either.”
If I wanted someone else to join me in the team room, I needed to demonstrate that it was a good thing to do by taking up one of those seats. But I also realized that to prevent the same pattern of thought from taking over, we needed to get a third tester seat in the development team room so we could all be together.
Pushing Back the Frontiers
For a few months, the second tester’s desk in the development team room went empty. But I kept talking to the other testers about it, asking them regularly to try taking the other seat. Eventually, one of the testers, Jim, tried it out. Jim wasn’t a fan, but he sat there for a couple of weeks, and we got some really great benefits out of it: He was consistently informing developers about defects that they were able to fix immediately without the waste of a defect report. Ultimately, however, he came back to the test team room. The benefits of sitting with the development team were not enough to overcome his discomfort at being in a more open office.
The other tester, Bob, was even less interested. But after a third desk was added to the development team room, he began sitting there occasionally. Over time, his ability to join the development team more regularly increased. He now sits in the development team room every day after the first hour of the day, with occasional breaks in that pattern when his stress levels are high. This has given him space to have a comfortable work environment while gaining the benefits of sitting with the development team.
Overcoming the Challenges
One of the most challenging aspects of making this transition was figuring out how much of the test team’s reticence was a matter of our introversion and how much was just a fear of change. It was difficult to know how hard to push while maintaining a comfortable and productive working environment. Are there some people for whom the benefits of transitioning into this blended environment cannot overcome the hardship of the change?
A couple of days ago, I found out that Jim is leaving the team. I don’t know if that provides an answer, but I know I will always have more questions.
This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.
Test Automation – Anywhere, Anytime