Organization that is deep in Waterfall
For organizations that are deep in Waterfall, it is sometimes hard to adjust to the Agile-Scrum methodology. One thing in particular is difficult is the role of QA. Waterfall oriented organizations typically have a QA department and the QA team does the final System Test and Regression test to ensure that the product is good for deployment. This is contrary to the Agile-Scrum principles. How does one get the QA team to understand this new way of working? Where does the QA team fit into this structure?
The biggest shift is that there is no more QA team.
This doesn't mean that there isn't a QA part of the organization. The organization could still be functionally-oriented, with QA as a functional organization, which could be useful for maintaining managerial independence. Another option would be to shift the QA organization to be more like a community of practice or center of excellence.
Teams that work on products would tend to be cross-functional teams. That means everyone with the skills needed to go from idea to delivery works together every single day on a cohesive team. QA skills are still vitally important for the success of the work. However, instead of QA being responsible for system test and regression, the whole cross-functional team is responsible for system test and regression. A key role of a specialist is to teach their specialty to the other team members to help them be more effective when doing a particular kind of work.
In my experience, the best way for people to see this as a good way of working is to do it and be ready to help them through issues. Explaining it without doing it isn't often helpful.
When people have to choose between the day job and change, you know which is going to win out. It's up to senior leadership to create enough of a sense of urgency in their company so the equation rebalances. It isn't your organization to change, but you can illuminate the gap between where it is now and Scrum, then extend a hand over that gap, and help people to cross if they want to.
How does one get the QA team to understand this new way of working? Where does the QA team fit into this structure?
to follow Scrum framework to address this challenge also requires reorganisation of teams as defined in the scrum guide. having a 'Definition of Done' for an increment would help you to decide if the product is good enough to release.
In the Scrum Guide, there is a role described. That role is a Developer. People that fulfill that role have the skills needed to turn an idea into a valuable deliverable increment. Notice I didn't say that they write code. I have a long background in Quality Assurance. I have found that my role as Quality Assurance Engineer changes in an Scrum or agile environment. Instead of writing and executing test cases, I help to ensure that quality is being built in from the beginning instead of being put in at the end. I help the coders to prepare and create unit, integration, system level testing that can be executed continuously. I help everyone to better understand the work that needs to be done and will represent stakeholders in discussions. I help the Product Owner in capturing descriptions of work such that it can be understood by the technical and non-technical staff.
I quit being a tester that validates things after the coders are done and become an analyst that helps to ensure quality is being considered and validated from the beginning to the end. Quality analysis is much more important and impactful than testing executions.
Just as an organization has to adjust to new roles responsible for Product Ownership so must they adjust for Developers and Scrum Masters. When an organization is having the issues you describe, it indicates to me that the organization is not wanting to change and reap the benefits of empirical decision making that is the core of Scrum. Instead they want to use certain terminology to prove that they are using the Scrum methodology. However, Scrum is not a methodology, it is a framework. The organization is proving that they do not understand the empirical benefits of the Scrum framework and are more concerned about having a process in place than in delivering incremental value.