The Love-Hate Relationship between QA and Development

Development and QA have often found themselves at odds. If you want to really get to the heart of the matter, it usually breaks down to one of these things: Process, Communication, Distributed Work Groups (Time-zone differences), or Roles and Responsibilities. Yes, sometimes there are blurry lines between these four things. For example, communication and distributed work groups can be the same thing (at least on the surface) or Process and Roles and Responsibilities might have over-lapping issues. If any of these four areas is a "weak link" in your organization, then more than likely there will be issues. In most cases, in a Software development environment, the problems are magnified between the two groups that should work best together - Development and QA. The following are some observations, stories and insights from myself and other software professionals I've spoken to recently.

So why bring this up now?

Over the past several years I’ve noticed a lot more QA Managers having a tough time with their development team counterpart. Over that same time-period, I’ve spoken with a lot of QA Managers who have a common complaint: QA isn’t given the respect or the voice in an ever-changing development process.

I decided to interview several QA managers to find out more and get some of the details of their own experiences.

In the “old days” of mainly working in Waterfall development process, QA had a really clear, well defined role. Once a bug was fixed by development and a new build was available, test it. Mark it closed, or tell development why it didn’t pass. That was basically it. So what has changed over the past 10 years that has created the "rift" in some organizations?

Agile anyone?

Then about 10 years ago or so, a lot of development teams started moving to an Agile development process. When I speak to people about "Agile" I often get the same answer: "We are Agile like" or we use the term "Agile" loosely. Or "we are sort of Agile." In one case, QA was left out of all planning sprints and even that very day 20 items were added to the upcoming development sprint without even talking to QA. Clearly this isn’t a true Agile process. QA should be part of the team – involved in sprint planning and suggesting which user stories can be tested in the two or three-week sprint cycle.

For many of the managers I spoke with, The Agile development process has gone through variations and permutations to meet the needs of the development team and culture. But at the same time, someone (perhaps the Scrum Master) needs to help guide the team and make sure that QA has been fully integrated into the Scrum team. This means having an equal voice (or at the very least a voice that is heard) when it comes to testing and sprint planning.

These communication and delegation problems seem to be worse where more mature companies, who for years have operated under a Waterfall methodology, have decided to move to an Agile process. I spoke with a QA Director who pushed really hard to move to Agile. Let’s call him “Larry.” Larry was pushing QA Automation to be integrated into the process. The Engineers and managers who had been there a long time said all the right things – but when it came to actually changing their way of working, it was a struggle. Yes, they organized into Sprints and had a Scrum Master, but almost all of the discussion and planning was done in a vacuum within the Development team (for example Larry wasn’t even invited to the first few meetings and found out by accident that there was even a meeting taking place). In this case Larry had to be really aggressive and fight to be heard. Eventually he was heard and was able to fully integrate QA Automation into the process. But it took over 6 months and a lot of perseverance.

Global realities.

When I was with Nokia, we had development teams working all over the world. Teams in Sunnyvale working with team in Atlanta, Cambridge, Romania and Finland where not uncommon. When I left in 2009 the teams where just starting to move to Agile and using teams in different time-zones was really difficult. The solution for most of the development managers was to create small scrum teams locally and divide the work so each team was responsible for only their own portion of the project. I remember really clearly there were two major problems 1. The Development or “Scrum” master completely left QA off the scrum teams. They decided only Unit Testing would be done for each sprint – then when they completely finished the project, they would give a fully functional product to QA and do “Maintenance” Sprints – (Sounds like waterfall to me).

And 2, they didn’t have trained Product Owners or Scrum Masters. So really, Development was trying to move to Agile without having the right training, management support or process in place and they were only looking at Agile from a Development perspective. Eventually they got it right but it took several mistakes and missteps (and teams getting proper Agile training) before they saw the results they expected in the first place.

The other problem was communication. For Agile to really work, you have to have daily stand-ups – where everyone on the team participates. Having distributed teams made this really difficult. Having smaller teams, in the same time-zone made a huge difference.

But what if you are “Stuck” with working in distributed work groups. My team at Nokia didn’t have a choice. Some of the developers were in Atlanta while another large part of the team was in Romania. In order to work together we had to find an over-lapping time in the day and schedule the daily stand-up in the morning for the US team, afternoon for the Romanian team. We figured out a process and method that worked but it took extra effort to do so. In the end, it’s about making it work. In this case, we could divide User Stories between the two groups and make sure that each team worked on their own Sprint schedule. When key components needed testing, the Romanian team tested for both groups. In this case, we were able to adjust meeting times, develop a method to both test and communicate across groups and time-zones. Again, it took people working together to figure out that if we didn’t solve this problem, it would lead to some pretty bad results.

Roles and Responsibilities

Several years ago I had two different development managers working on the same product but in different locations. On the daily stand-up call each dev manager would give direction to the other manager's team. It turned out that both managers thought they were the main manager, even though they both had the same exact title and had the same number of engineers reporting to them. for some reason, they each had it in their minds that they had "the lead role." This caused multiple delays and a lot of confusion with the two teams. Not until we worked out each Dev Manager's actual role and responsibility could we get the project back on track. In this case, someone from upper management had to spell it out for them. In my interview process I often ask "If you could change 1 thing about your organization or team what would it be." In most cases, if it's a QA Manager, a Dev Manager, the most common reply is: Roles and Responsibility. It might be with upper management, it could be with other departments or it could even be someone from another functional team. Knowing who does what and why is a really important part of any organization but especially in a development team.

What works?

I asked this very question of several successful Development Managers and QA Managers alike. In every case, where both teams work well together, they said “Our Development Process.” When I asked for more details it turned out that teams who successfully implemented a true Agile development process, had Engineers who felt like they had a voice and their point-of-view was heard. In other words, they felt like they made a contribution to the team and that their contribution was appreciated. Again, in every case where the team had achieved this “success” in their process, it took multiple rounds of trial and error. Not once did everything work “out of the box” on the first try. I had one manager tell me that it took 2 full years of constant improvement before they finely “got it right.”

Working together

QA and Development have to work as a well-oiled machine and the only way to do that is for everyone to have a role, have a say, and be heard. It’s not enough to say you’re “Agile.” You have to adapt to the team size, personalities, communication process and remember that the main goal is to deliver a quality product. If you’re team is having trouble working across functional teams or even time-zones, ask yourself where the problem is: Is it with Process, Communication, Time-zone, or Roles and Responsibilities? Then work as a team to solve these issues. If your problem is too large to solve quickly, come up with a plan that breaks it down to smaller, manageable, achievable goals. Even small steps in the right direction will help. In the end, the entire organization will win.

If you've had problems in any of the four areas outlined in the opening paragraph, I'd like to hear from you. Connect with me on LinkedIn and tell me your story.

Mark Andrews is an executive with Waverley Software., a California based Software Engineering firm with engineers in both California, The Ukraine and Vietnam. Mark has over 25 years experience in delivering global software solutions across a wide variety platforms and technologies.

Copyright (c) 2017, Mark Andrews, all rights reserved.