Team Doesn't Want to Share Ownership of Quality?

🗄️ Archive
1

Following on somewhat from my post “What's Your Dev - Tester Ratio?”, I was wondering how you manage a situation where your team does not want to learn more about testing and they don’t want to have shared ownership of the quality of the work that’s being released?

What are the steps you would try in this situation? Or perhaps a better question is: where would you start?

1 Like
2

It may seem simple but I would start with Why?

Try to understand what makes them think/feel that it would not be a benefit, then use an old sales technique I was taught AIR.
Acknowledge - I can understand why you would think that
Isolate - Is that the only thing (in that area) that concerns you
Resolve - Heres why that isn’t actually a problem

3 Likes
3

I think the first step is to have an agreement with management and leads that it something the company wants. Having that, a common message will arrive at the teams that Quality is a Team responsibility. If the message comes only from testers and then different messages are shared with team members from other senior roles, I think is almost impossible to achieve the goal of having shared ownership of quality.

3 Likes
4

How I see it…

Quality is value to some person(at some time).


Not everyone’s opinion on quality matters. And not everyone is speaking about the same ‘quality’.
Examples from the post above: “Zero defects is high quality., User-friendliness is high quality., Low development cost is high quality.”

Two types of quality based on ownership:

  • quality of your own work;
  • quality of a project/product;
    You could have one without the other. Rarely you’re in charge of both.
    The quality of one’s work is the responsibility of that person. The quality of one’s work can impact the quality of the product. Quality of a product release is not the responsibility of the person that developed it.

Testers or developers are usually only in charge of the quality of their own work.
Developers build - to the best of their knowledge/abilities and considering the constraints.
Tester finds quality gaps, risks, threats, and report/inform managers about them.
That doesn’t make them in charge of the product quality about the product to be released.

The managers and stakeholders are leading the direction and taking all the decisions on quality.
Sometimes development team members will make decisions without approval, or on behalf of someone else.
This is a risky thing, as you could either get yourself in trouble or you put someone else in a tough spot when having to motivate the budget, resources spent on some decision that they haven’t made.

To put on the development team the responsibility for product or project quality I think it’s a big mistake.
The development team most often is disconnected from stakeholders, department managers, clients, direction and roadmaps for a product, financial stuff, budgets, logistics of the project, etc…

Release management:

  • The work of the development team, including tester’s are getting to the release manager/s.
  • I also feel like the development team shouldn’t be the release managers either. Or if they are, to do it in collaboration and in agreement with the product manager/s and have the product manager own the task/decisions.
  • The release managers make an informed decision to release or continue to work on things. They analyze: what there is, what they would have liked to have, what gaps/problems there are, what risks and impact the release would make, etc…

What would I do if I feel the quality of a product is bad:

  • I’d have more often discussions with the release manager, product owner, and increase the bug advocacy.
    What would I do if I feel the quality of a developer’s work is bad:
  • Most probably nothing, or have a raise of awareness either to the person, to the colleagues, or to the manager if all else fails.
  • I could also propose things that could motivate the developer, or help him on a personal level, or make some suggestions to have the developer work on something he likes or he’s strong at.
1 Like
5

At one level software quality is a lot like marketing division spending. Both deliver business value over time, while both have a very short sell-by date for their efforts. The value they bring is intangible to some, and since, they both go to war in the real outside world, they are key to supporting the business.

The difference is that the tester knows that it’s easier to loose a customer, than to make a new one. Marketing have that job, which in reality makes them far more expensive.

1 Like
6

Give people skin in the game - if engineers have to answer support questions, deal with outages of their service, etc, it can lead to some significant leveling up, as well as folks realizing that quality means a lot of different things.

edit: s/lean/lead/

3 Likes
7

@beardedtester - on a lighter note, what if the team uses AIR against me when I try to use AIR on them ? I wonder if I’ll end up letting them work in the old ways.