I find myself from time to time saying to people that Agile is about as soft and fluffy as a velvet covered sledge hammer.
Somehow people get the view that all this team stuff is fluffy touchy feely - lots of talk about feelings and hand holding and kum by ya. That may be some folks' experience of Agile, but I've been told that anywhere around me people experience Agile as a no nonsense, authentic, often times confronting and deeply rewarding way of working together.
It's a way of working together where participation is predicated on membership and continued membership is predicated on continued participation.
That we are paying attention to some aspect of performance at all, tells us something. It tells us that there is some thing (an output, an outcome, a result, a deliverable, a relationship) that we care about, and at least an aspect of the thing we care about is somehow supported by this thing we call performance - and quite possibly a minimally acceptable level of performance.
To the extent that the thing we care about is supported by current levels of performance, performance as it stands is largely transparent. To the extent that the thing we care about is either not adequately supported or in danger of not being adequately supported by current levels of performance, we start to regard the current levels of performance to be in breakdown.
We may see this happening over time as the standards for what's considered minimal acceptable for a key performance indicator become progressively higher.
This is the experience for many folks as they begin to transition from monolithic delivery to incremental delivery. As part of this transition the standard for minimal acceptable cycle time for system integration may be required to move from 2 quarters (a not uncommon post feature-complete bug burn-down cycle time for large waterfall project) to 2 weeks (a typical system integration demo cadence for an Agile program).