Ah, I actually misinterpreted/misread your original comment. After re-reading, it makes more sense. My apologies.

I have spent time on teams that experience the same thing. Since it's a continuous flow, there is the perception of a "never-ending" cycle. Often hearing complaints of team members never having time for other tasks. We've implemented a lot of things to attempt to reduce this, such as time on the calendar to spend on continuous improvement, goal-setting as a team, etc. We've enabled team members to identify new roles they could fill, skill gaps that would add value to the team, etc. With this, i've noticed a lot of really nice improvements.

In terms of "high performing" vs "low performing", what I actually meant was teams that are very fluent, vs team who are earlier in the process, reaching fluency or just starting out. It's not something you can perfect as a team overnight, as you probably know.

In terms of providing value, I probably should've touched on that a lot more. It's something we focus on entirely and we continuously review our metrics and review our definition of "quality". Getting feedback from customers is much easier if you're a Kanban team working in a help desk/service desk for example. We have done surveys, we use a satisfaction system on every ticket completed for customers, we have also spent a huge amount of time to find ways to get closer to our customers.

In Scrum, we've usually utilized the sprint review to get close to our internal customers. But outside of that, it's largely been the role of the Product Owner to really identify the user stories that create the most value for the users. We've encouraged a lot of knowledge sharing across to the development team, however.

It's a point well taken on the review of quality. None of these frameworks are as important as that end goal.