Reddit mentions of The Goal: A Process of Ongoing Improvement - 30th Aniversary Edition

There is a really great solution that works great when it is politically practical: fold the dev and QA team together and tell them that they own releasing a quality product. That is the only real fix I've seen.

If you are stuck with separate teams, then I have two pieces of advice...

First, stop tracking anything that is per-discipline; only track "feature is ready for release/not ready". The reality is that "dev complete" is not a useful state from the business perspective, so just stop tracking it. Your devs will likely resist this because they have been getting rewarded for "dev complete" even when it's crappy quality. You want them thinking about optimizing the "dev + QA" time, not purely the dev time.

Second, start doing bug categorization. I wrote up how I did it here. I had *amazing* luck with the first team I did this with and it was a team with separate dev/qa roles; my devs felt that having "foreseeable" bugs come up in the feature they worked on was a pride thing. I don't remember the numbers, but merely by reporting the stats monthly at the end of an iteration, they went from 45 foreseeable bugs in the first month to 4 foreseeable bugs 4 months later, and that was with me expanding the definition of foreseeable along the way. It drove dev/qa discussions in a way I have never seen elsewhere and pulled in our product owners in a very agile way as well.

I also recommend that you go read "The Goal" by Goldratt as it provides some insight into optimization across groups (others recommend "The Phoenix Project" as that's IT-based, but I think "The Goal" is a better choice).

I also wrote a blog series on applying the theory of constraints to software; you can find it here. Read from the bottom up.