My first question would be: Why are things ultimately failing in QA? What infrastructure, knowlegde or interactions are missing to permanently reassure the team if the current state of their work will pass QA?
Whatever product your team makes, it should not have relevant defects that only show up in QA.
Agile development is just a tool, not a magic incantation. For Scrum: Committing to a Sprint backlog makes no sense when the product still fails after the Sprint is finished. There should be no after . Done must be done - if it’s not you’re not doing it right. If possible I’d completely focus on fixing this point first.
(Background: Agile development, then coach since 10++ years. Now have a small startup building some niche BI software. (Interestingly coaching other people for money does not mean you’ll be doing it right yourself.))
Agile development is just a tool, not a magic incantation. For Scrum: Committing to a Sprint backlog makes no sense when the product still fails after the Sprint is finished. There should be no after . Done must be done - if it’s not you’re not doing it right. If possible I’d completely focus on fixing this point first.
(Background: Agile development, then coach since 10++ years. Now have a small startup building some niche BI software. (Interestingly coaching other people for money does not mean you’ll be doing it right yourself.))