I believe in having QA as part of your software team. While developers need to own the quality of what they're shipping, a good QA person bridges the gap betwee

I believe in having QA as part of your software team. While developers need to own the quality of what they're shipping, a good QA person bridges the gap between engineering and product, and serves as a gating function for what gets shipped. You can't automate testing of everything, although certainly you need automatic testing where it is required or pragmatic. Blue/green is great, but when you're relatively small then avoiding any users having a shitty experience is a reasonable goal. Anyway, with a QA function, you need some kind of release cycle. I don't believe in prescriptive sprints where either developers are stressed to hit an arbitrary end of cycle deadline or developers sit on their hands because the phase of the sprint dictates no new work (which I've heard of happening in some particularly agile-diseased companies). I think a reasonably regular cycle that aims to ship what's ready fairly often is a good middle ground that keeps quality high, keeps the product evolving, and maximizes developer keyboard time (and of course you also need the ability to hotfix production occasionally.)