Why can't QA's share expertise and suggest new ways of working

Question

I work as part of an eight-member agile team. When I joined the company I saw lots of problems in the team. I decided to share my past experience to help the team but the team saw me as a small person, challenging them.

My question is, if agile is about the team and the team takes responsibility for the failure of the project or sprint then why can't the QA suggest new ways of working?

Do you think it's unfair to hold the QA accountable when they are treated as a small person?

---

I did fair bit of research before suggesting new ideas. I also removed any ownership claim and did not involve senior management team but still the team saw me as a threat. It's definitely to do with my role as a QA.

Senior management recently sent another guy to help add new processes to the team and the team actually listens to him. He's doing everything the way I was doing but senior management team likes him so the team can't say or do anything to him.

He said it's not QA's responsibility to add processes or suggest anything that's why the team don't like it. They see you as a challenge.

Answer 1

It might be how you're suggesting these changes.

It probably has nothing to do with your position (QA), per se, but more to do with the fact that some new guy is coming in, telling everyone that what they're doing is all wrong (despite not having been around long enough to understand why it's done that way).

In addition, you could even be seen as a threat, especially if you are involving upper management in these decisions. You could be seen as jockeying for respect and credit for providing all these new ideas for the Team to use, which in turn would make the other Team members look worse by comparison.

My advice is to do the following two things, in order:

1. Understand why the current process is the way it is. Performing this step might even make you realize that your 'improvement' is either not worth it, or perhaps even harmful. Never assume you are right before you do the sufficient research to determine if you are right.
2. Work with the Team to transform 'your idea' into the Team's idea. You need to make sure that you remove any ownership claim you might have to the new process. That way, instead of being 'the new guy's idea', it will be 'an improvement to our process.'

Answer 2

Anybody in the team can make suggestions for how the team can perform better, also new team members with a QA background. There are, however, two things working against getting your ideas accepted.

1. Change is hard. If ideas are not backed with authority (either formal or informal), then the team often finds it easier to dismiss the new idea than to make the suggested idea. As a new team member, you have not had the time you build up an informal authority by showing that you always have the team's best interest in you heart.
2. In my experience, people with a QA background are not among the forerunners in adopting agile methods/mindsets. If the team has had a bad experience with a QA member who tried to change the processes back to a more formalized, waterfall-like format, rather than a relatively free agile format, then the team might be less accepting of your improvement ideas because they fear you also want to back out of agile. That fear is completely independent of what direction your ideas actually would take the team in.

Answer 3

Thank you for having the courage as a new team member to raise concerns and propose improvements. There are some good thoughts in the other answers.

One part of your comment to Bart speaks volumes: "there's one person who doesn't. She's the probject manager." If she is operating with a classic, command-and-control mind set, then that could be the root issue. There may be a lack of a complete agile mindset.

You're frustration is understandable. Continue to learn about the group. Understand the current modus operandi and the why behind it. Continue to build relationships with the other team members. Share your thoughts. Influence what you can.

Things should improve. If not, then you have a decision to make.

The input of all team members should be taken seriously. It is wrong to hold any one person or role accountable for team results.

Answer 4

As a Software Quality Engineer (for about 10 years now) I have been giving teams advice on how to improve their process all the time, with great success.

He said it's not QA's responsibility to add processes or suggest anything that's why the team don't like it. They see you as a challenge.

I have to clear disagree with this remark, hopeful I can explain why I think it is QA's responsibility. Let's start with the three aspects of software quality:

• Functional quality: This is what most QA focus on, e.g. testing from a user perspective.
• Structural quality: This is was Agile QA should focus on if you ask me. From the Agile manifesto: "Continuous attention to technical excellence and good design enhances agility.". Teach developers to build testable code and how to refactor-safely with the goal to create software that does not resist change.
• Process quality: Going from requirement collection to product delivery. Actually the whole SDLC should be a QA responsibility. There is so much to improve, so many risks to minimize. Focusing on Agile risk management helps to get influence, as it is a clear QA task to remove risks in the process for the users and sponsors competitive advantage.

These three aspects are of equal importance. If you are only a functional tester it is hard to get respected on vision in the other quality aspects. Structural quality could be a developer responsibility, but often they lack the knowledge and urgency to improve here. Process quality could be the main responsibility of a Scrum Masters, but they often focus on project management and not product quality. Even if the Scrum Guide describes this: "During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate". So YES there is a lot of overlap with other roles, but still enough room for the QA to focus on.

When starting at a new company I would do one-on-one status-quo interviews and or training with all personal (CEO, Managers, Key-Users, Key-Stakeholders, Developers, Product Owners and Scrum Masters) explain them the difference between these three quality aspects, internal vs external quality and maybe the Agile testing quadrants and which skills this entails. Showing you have broad knowledge of all aspects of software development. This will help accepting suggestions you make greatly, set yourself as THE quality guy or girl.

Something I have learned over the years:

• Act confident, but with respect. Truely believe what you advocate.
• Describe or visualize the problem. Let the team find a solution. Only suggest solutions when they ask you. This will make adoption of changes easier. Even better let the team do a research activity, not a single person.
• Changes in culture are slow, this can take up to three or more years. The ones repeating often, but quietly tend to win this culture change race. Making a big fuss is never a good strategy for cultural change.
• Being a Scrum Master gives you greater influence. Reading up on Agile and Agile testing can be the first steps into this path. I have been working in a dual role (QA + Scrum Master) since 2009. Seems to work great for me.

Suggestions:

• Ask the Scrum Master or Agile coach to help you implement a change in behavior. Let them describe the problems to team.
• Use retrospectives and keep repeating serious process issues you see them. Try to not talk in solutions. Explain the WHY, not the What and How. Same as with perfect User-Stories. :)
• As a last resort I always like to quote Martin Fowler: "If you can't change your organization, change your organization!"

Answer 5

Regardless of what it is, it is not how a software organisation should be working. Success in & for an organisation relies on a lot of factors and one of them is participation.

There also remains a possibility that - you might not be aware of a bigger picture. What you are suggesting might seem to be a solution from your perspective but may require change & transition management or the case of stakes not being transparent to you. I think they have taken your recommendations seriously as the action is already there. So, regardless of who does what, your input is actually paying off and you should be happy about it.

But anyone who has been in management capacity for more than 5 years will easily spot a fault here. Your organisation seems to be a initiative-killer. They should be embracing that people are willing to contribute for betterment of the organisation. If it is because you are QA then you need to stop thinking and start looking for better opportunities.

QA team should have authority in at least suggesting improvements but then it really depends on how the organisation has defined quality.