I would suggest that you need to start by presenting a comprehensive approach to QE to the team so that they can see how it will fit in with Agile Development.
For me a comprehensive approach to QE basically means a comprehensive approach to testing.
For this I start with these four quadrants:
Integrated | Performance
Unit | Exploratory
You need to be sure that the base code works as intended (Unit Tests), that it integrates correctly with datastores and other dependencies (Integrated Testing), that it performs reasonably (Performance). Finally you want a human to look at how everything works together to achieve the desired business goals (Exploratory).
I then look to talk about how long testing takes - particularly writing automated testing and most particluarly in getting a framework 'off the ground'. I also talk about the testing ratio of the tester/QE person (if broken out separately). If there is 1 tester to 4 developers and some tickets take twice as long to test (a common scenario) then there is an inherent problem. Having laid this out I then suggest the solution: we are a team and everyone does testing. Developers should already be familiar with the value and need for unit tests so this is just building on top of that.
In your case, for the question of where/how/when to start with making QA (testing) more efficient if the team is transitioning from waterfall to agile:
For unit tests by developers
Writing unit tests for code is fundamental to current software development. It didn't exist for me 20 years ago but now it is just a basic requirement. It's not just 'a good practice', it's the accepted basic way to make sure the software keeps working.
So if folks aren't doing unit testing now it's time for more action than just an email or a lunch-and-learn. Folks need to be re-trained. It can be on-site or off-site but we are talking weeks and months here not hours and days. New folks may need to be hired. Existing folks may need to learn to how to balance the value of their experience with the need to continue learning and changing. I am.
For integrated UI testing by developers and QA
Drive change with the common theme of where, how and when QA tests, to emphasize the change in testing close to production - a characteristic of waterfall - to testing as part of development as required by Agile development.
- Start with production
- move to testing staging
- move to testing locally
- Initially start with QA testing manually to learn the domain and workflows and learn any existing bugs or 'features'.
- Then move to simple UI automation with scripts and gui IDE tools.
- Then move to programmatic solutions using web driver
- Then expand to multi-device and browser testing with both physical devices and remote services.
- Start by testing current production
- Move to also testing a staging environment for code about to be released
- Move to also testing Pull Requests before they are merged into master
- Move to also testing alongside development and planning testing before development starts