Re: "Quality" is a structural attribute, not a bolt-on
I'm going to disagree with you on that. There is nothing fundamentally wrong with agile development. It does not permit untested work. TDD (which if you're doing agile correctly is kinda mandatory) means that you should have your tests written before you start
copy pasting from stackoverflowwriting code. If you are doing things properly, you are getting input from QA before you design the tests in the first place. It was never about removing QA from the process. Everything about it is to remove the distance between the subject matter expert and the code monkey so that misunderstandings can be discovered and rectified much sooner.
Of course, you are probably thinking about that other definition of agile favoured by PHBs the world over, where any form of analysis is disregarded because agile, any form of planning ahead can be forgotten because agile, and any form of QA can be ignored because we once showed the devs how to install nunit. That is of course bollocks.
Quality is derived from culture. You need a culture that is ashamed of breaking things, ashamed when their test case design fails to detect a breaking change, is proud about coverage (real, not by fooling the tools), hates when something slips through to QA and really hates when a customer suffers a bug.
Companies that only value story point velocity, that don't invest in reducing technical debt inevitably find themselves producing code which is a quick hack around some work around ona half designed proof of concept which resists even basic enhancements, which then hurts the velocity, so no time for paying back that technical debt and the QA cycle needs to be cut to make deadline. Sigh, I guess some people cannot learn.