Yes. But No.

Have you ever been in a project where after a few days you knew exactly what needs to be changed to make work more pleasant and effective for everyone?

We all know those LinkedIn’ish slogans – “we are too busy to improve“. Got it.

Problems

However, imagine that you are a tester in such a project. Immediately you notice that:

• There is no separated test environment
• Some crucial parts of the system are not covered with testing at all
• Due to the lack of adequate quality, product failures constantly occur, causing both customers and the company’s reputation to suffer.

You think – “Damn – just a few simple changes that no one has thought about before, and our project life will turn into a land of milk and honey. I’ll be the change I seek!”.

Step 1

You start by talking to the rest of the team, Surprisingly, it turns out that everyone dreams of the same changes but cannot make them. You can feel an atmosphere of discouragement and increasing frustration.

Step 2

Like a knight in shining armor – you stand in front of your PM, PO or other manager of this mess and tell the words of truth:

• testing environment
• regression testing
• performance testing
• test automation
• more awereness
• less features – more maintenance…

and when you envision this paradise on earth, these revealed truths, you hear: “Yes. But No.”

Oh, I’ve heard “Oh, that’s a great idea (YES), but we don’t have (time/budget/skills/we are to small company/ to big company … you name it) = NO”.

Usually, it seems that most of the people in the development team feel the same, sees the same flaws, and wish to improve, but they’ve tried so many times and heard NO, that they just stopped.

Why do Product Managers, Product Owners, Managers keep making the same mistake and give up on quality?

My opinion-driven assumption would be:

• The main product works in production and is making money for the company. It has flaws, of course, but what software doesn’t have flaws?
• The markets change rapidly, the competition is vast, so investing in quality is pointless, as MVP makes greater value for the company than a bug-free one. The company can sell it anyway.

It’s quite a similar situation to buying clothes in chain stores. On one hand, you know that they have, most probably, been manufactured in non-ethical conditions, exploiting people’s health and strengths, on the other, you still buy it and support the brand, as “it’s only 9,99”.

• You are a member of the development team, and your opinion is extremely important for the company (YES), but you are at the bottom of the company “food chain”, so with your decision-making ability equaling zero, you’ll most probably hear NO.
  Wanna make decisions? Become a manager or a CTO 😉
• “It won’t work for us” – it’s my favorite answer of all time.

To the last one – my answer will be this talk:

How make them (BUSINESS) understand?

They’ll understand after the first, second, or if they’re really taught players – third big production breakdown, or after the first lost money or piles of complaints in the social media.

Then you are allowd to sing: “I told you so, I told you so….”

Can you force the changes earlier? It depends.

Do you have enough patience to wait? It depends.

The answer is never easy.

Let me just remind you the universal truth – the Quality Triangle:

You can have your product delivered either Fast or Cheap or with Good Quality. It’s unlikely that you’ll have all of it in one product. So this needs to be a common understanding both from the business and developement perspective – what is the best approach in your situation.

The quality should be the whole team’s responsibility. I can keep repeating it over and over again.

Quality takes time and that’s OK.