Quality mindset

How do you get Built-In Quality with that approach?

Had a strange discussion the other day in the project. We had a Release Meeting and my team was showing the current state of testing, defects and so on. During the presentation I intentionally said my Def-M, he should highlight in the Dashboard how long bugs are open in our product (we have a couple of them dragging on for more then 6 months). Of course this caught my managers eye.

In the discussion after the meeting we were talking how can we improve the situation. I was pushing for a time slot in the sprint planing for debugging and bug fixing, basically we have to see feature and bugs (at least) on the same level in order to have a good planing and tackle the bugs early in the development cycle.

Other idea was very strange to me. It was proposed, that we "open up a new bug fixing team". In the beginning I thought we were talking about some sort of triage or debugging team, who would try to reproduce and create logs of the bugs. Then the feature teams, who have a bug in their code, can pick it up and find the exact root cause before fixing it. But no, the proposition was that this "Bug fixing team" also fixes bugs in other peoples code! So although this could be a good idea, when your product is already in the market and you have only limited resources to take care of the feedback, I think it's a majorly bad idea for a product in active development.

Why? Because people making the bugs should also fix them! With this special "Bug fixing team" you basically saying to the developers: "Hey, just write code! Somebody else will pick up the slack, when it crashes and take care of your mess.". Not really a good idea, if you want to have Built-In Quality in your product.

License: CC BY-SA 4.0 Discuss on Mastodon