By "not managers", I meant not the managers of the people involved in the agile team. I clarified this by also saying "conflict of interest".

As for the authority piece, it's well known that agile teams need to have top-down buy in from the organisation (to avoid unsavoury situations such as marketing performing "drive by" requests on developers), so "authority...to get through barriers" is a moot point when it comes to looking after the team's interests, as in theory there's a mandate to do things in an agile way.

Seems to me there are a few issues here:

• The team leads as scrum masters is a conflict of interest. Managers should never be scrum masters, as often scrum masters need to go against management in order to get the team through blockers. Additionally, they can put undue ("you report to me") pressure on team members during scrum. That balance needs to be maintained;
• Scrum masters, if picked from the development team, should be rotated to avoid keeping people out of the loop; but
• Ideally they should be someone who is from a project management background. If you're doing agile a lot you'll want a dedicated scrum master. I never really bought into the idea that developers should be scrum mastersâ"they should just be trained in the right skills so they know how it works, but their core skills are unlikely to be organising people.

If your company is "doing it right" you can raise these issues in the retrospective and hope they get picked up. If they're not doing or respecting retrospectives then they're doing it wrong, and all bets are off.