Measuring individual performance

Why do the Developers have a manager at all? Whose idea was that, and are they aware of the issues it is evidently creating or perpetuating?

Ian, I am not sure about whose idea was it. I am merely a scrum master in the organization!

In Scrum aren't the Developers supposed to hold each other accountable? Does anyone understand and value the concept of a self-managing team, or do they prefer to go back to the industrial revolution's ways of micro-managing people and getting the same old results they hoped would change with Scrum? 

It isn't possible to equate points to hours in the world of complexity.

I have normally observed that when a member is an underperformer, the team is the one with the major concerns. They are the ones who come to the scrum master with their concerns. But is there a way to find out when a single individual is the one who is an underperformer? Or is it the development team that will voice their concerns?

I'd suggest that the best agile performers are those who help an organization to identify and overcome its constraints. The worst performers are those who merely accept them.

Whenever a manager makes a decision affecting a team, for example, he or she robs that team of its self-managing creative potential. Seen in that light, perhaps certain parties ought to be circumspect when assessing the performance of others.

I have normally observed that when a member is an underperformer, the team is the one with the major concerns. They are the ones who come to the scrum master with their concerns.

Perhaps the symptom is that the Developers first come to the Scrum Master without trying to resolve it themselves, and there is an impediment here for the Scrum Master to work on, which may be the Scrum Team's inability to self-manage. Rather than resolve a conflict directly, there are better choices and tools available for a Scrum Master: lean on Scrum values, use empiricism, the Sprint Retrospective, coaching, facilitation, etc. 

 is there a way to find out when a single individual is the one who is an underperformer?

This is my opinion. Once you start measuring an individual team member's performance based on story points delivered, it's game over. This will crush the spirit of team work. Would one Developer stop to help another if they are concerned about completing their own points?

is it the development team that will voice their concerns?

I would hope they would try to work through this internally and do all they could to help their teammate before taking it to a manager.

First, I'm going to rant a little.  <rant>  Where in the Scrum Guide does it mention any role with "manager" in the description?  Where does it say anything about someone outside of the Scrum Team telling people how they have to work, setting performance goals for them, or measuring individual performance against each other?  Why can't people understand the self-organizing, self-managing concept?  </rant>  Ok, thanks for indulging me.

Let me provide a scenario.  Developer A is the User Interface expert on the team.  Developer B is the database expert.  Developer C is the best at building algorithms.  They often do the work that fits into the their expertise.  The team embarks on introducing a new feature that will provide information to other systems via an API and the team expects that this work will span multiple Sprints.   There is no User Interface work for this feature and all Product Backlog Items related to the feature have been placed at the top of the Backlog by the Product Owner as this is the most important thing needed by the business.  If you used Story Points completed as a measure of performance for individuals, Developer A is going to be very low performant.  They might be able to do some work but it will take them longer as it is outside their area of expertise. 

For example, 1 Story Point - 1 hour as per a developer effort to measure how much a developer is delivering ONLY. 

Another example.  Story XYZ is estimated as 8 story points.  Developer Coder and Developer QA will be working on the story together.  Developer Coder discovers that the code changes are more complex than originally thought after they start working.  It ends up taking Developer Coder 10 hours to complete the coding.  Developer QA realizes that due to the new information and the implementation taken by Developer Coder that testing is actually going to be much easier than originally expected.  They end up using 1.5 hours to test.  So in your example, the Developer would be over performing on this story while the QA would be underperforming and the estimate of 8 is entirely irrelevant.

Story points are not meant to be used for measuring performance.  They are estimates.  According to Merriam-Webster they are:

a rough or approximate calculation

an opinion or judgment of the nature, character, or quality of a person or thing

They are not measurements in any way, form, or fashion.  This link is to an article written by Ron Jeffries who is said to be the creator of Story Points.  I suggest you provide this to your "Agile Managers" and to your team. Then have discussions with all of them on why Story Points are not measurements of productivity but can be useful as an estimation tool.  

You might also benefit from reading and sharing the Evidence Based Management (EBM) Guide provided by Scrum.org. Then have conversations with everyone on how to put in place indicators to help determine the effectiveness of what is being produced by the Scrum Teams.

Then you should also have discussions with everyone on how self-organization, self-management works.