Understand advantages of early and frequent feedback.

Early testing is a widely known term in the testing world. In old days testers were told to start testing early in terms of reviewing requirements and doing the static analysis of the content or documentation. As per Agile model fundamental remain same however it goes to a wider team instead of just a tester. It encourages early testing in terms of having a lot of unit tests that should cover product major requirements and business rules. We get defects when developer writes the bad code, misses a requirement completely or doesn't understand the business rules or requirements well. Early testing mitigate these risks. Using latest/ behavior driven development tools e.g. cucumber, behat, specflow and codeception, Business Analysts can write the specification by examples and developer then write test automation against these examples. Frequent feedback then can be provided on the regression features of the product by running the automation code.
The second and most important feedback in agile model is the feedback received from the end customer or product owner during the demos. These demos can be organised during the sprint after each story completion or at the end of the sprint during the sprint review. The important part is to get fast feedback and to fail fast if we have to. We can then adapt,learn from the failures and deliver a better product based on our learnings.
Advice from author and Practice Exercise
I have been working on the projects following agile for three year now. In these three years I have worked on healthcare, energy and insurance products. In all three projects I experienced completely different flavor of agile.
In healthcare projects we were following monthly sprints model to deliver a working solution to our customers.
In energy we were developing a new digital platform including android ios and Angular JS web apps with platform modernisation.We were developing a new feature in each sprint end to end. There were 5 teams working in parallel but on different features e.g one team was working on login logout feature, second on payments , third on customer billing, fourth on Single sign on and data migration and fifth on salesforce. Features were delivered in production after 10 weeks. They called 10 weeks delivery a programme increment.
In insurance projects, the scenario was completely different . I was working in a scrum team of 12-14 members. Here again we had 4 teams, but they were not focusing on features. In this scenario as it was the project about implementation of an out of box solution into an existing business, they were working on developing the components of the project e g one team was focusing on the front end configuration of screen fields, field validations, business rules etc. second with integrated to third parties web services e.g geocoding and motor reg look up, third was on integrating the new system with the legacy system using a Middle ware called Mule.
The common thing in these projects were daily stand ups, regular and consistent feedback during demos. In all scenarios teams somehow became self organizing, disciplined and focused on deliveries
I thing the crux of this whole thing is that in this industry everyone is at least trying and in the effort they are adapting and changing for good.
So my 2 cents are if you join an agile project listen a lot, try to understand the circumstances and culture of the project, team, business, testing and development practices. See where you can add the real value and then consult accordingly.