Is my boss Agile?

He's created a multi team sprint review that lasts about two hours in which each team talks about the work they did and show something they created during the sprint. It's mostly just the team members from each team who attend.

A cross-team Sprint Review is not uncommon in scaling situations where there are multiple teams working on a single product. Both Nexus and LeSS replace the team's Sprint Review with a cross-team Sprint Review, while some other scaling frameworks call for both. The scaling frameworks do call for outside stakeholders at this review. It does depend on the organization and how its structured, but I would expect representatives from the product management organization to be able to review the work done and be able to provide feedback into the prioritization of the Product Backlog for upcoming work.

Now he's asking me to present multiple metrics at each review that span across all teams.

I don't believe that a Sprint Review is an appropriate place to talk about metrics. I realize that the Scrum Guide does refer to talking about what problems the Development Team ran into, but I don't feel that this is the appropriate venue for this type of discussion. Instead, it should be focused on the work done, not done, and how to proceed forward to add the most value to users and other stakeholders.

Many of the metrics that you mention may be useful inputs to retrospectives, either for individuals or cross teams. The scaling frameworks that I've mentioned earlier also do account for cross-team retrospective activities, and having data about progress and state of work would be useful to help guide discussions. However, I would think that these wouldn't be too difficult to generate and should simply fall out of whatever tool that you are using. You may need to build some reporting capabilities and dashboards, but I don't see anything objectionable in the list of metrics that wouldn't be something that a product management organization couldn't use for longer term planning, forecasting, or prioritization or that teams or the engineering organization couldn't use for understanding their work done and not done.

After reading your situation Compton, I have the following feedback:

• Who is the Product Owner for your team(s)?   Are they present during this combined Sprint Review?   
• How does a so-called "Sprint Review" attended only by the Scrum Teams and your boss promote empiricism (inspecting and adapting)?
• What level of Agile/Scrum understanding/training does your boss have?
• The metrics being requested seem to be either activity-based or output-related.   None of them measure outcomes or impacts of what the teams are delivering.   Why is your boss concerned about the former, and not the latter?   Just because something has a number and can be measured doesn't necessarily mean it should

As a separate concern, I would push back on any attempt by management to utilize story points in any sort of post-delivery analysis.   That is a complete misuse and misunderstanding of story points.

Your boss seems to want to maintain existing metrics.   A good question may be to ask him why each of those metrics has meaning to him?

We do not have feature teams, but instead we think of our whole org as a feature team where any team can pick up a feature/epic/story. This leads to many dependencies and a need for everyone to know what's happening with every team.

Why don’t you have genuine feature teams then? Why aren’t those dependencies something your boss wishes to be reviewed? Does he intend to sponsor the organizational change needed for better agile teamwork?

Have you considered asking him what problem he is solving by these metrics? He most likely has a perfectly reasonable reason for it, at least from his perspective. There are hardly any people who come to work every day with the intention to make everybody else's life as difficult as possible just for the heck of it.

It could very well be that he has learned that transparency is a must-have in an empirical approach. Maybe he thinks he is helping the teams by making things transparent?

The Scrum values Openness and Respect come to my mind. Talk to your manager, rather than about him on a forum. ;) 

I will admit that my initial reaction to your post was "WTF is wrong with the manager?".  Then I actually read it a second time and paid attention to you what you said and what he asked.  At this point I agree with everything said in the previous replies.  I think this is a combination of a manager that A) doesn't quite understand how to gauge individual performance in a team based process and is struggling with old style management, B) is trying to understand what is going on within the teams and C) needs to have a deep, open discussion with his Scrum Master(s) so that they can help him understand how to best enable/help the teams.

For A: As a Scrum Master help him understand how old style individual contributions change in a team based process. Individuals no longer should be encouraged/rewarded for heroics and instead should be encouraged/rewarded for helping to raise the entire team to a higher level of success

For B: This sounds like the level of transparency offered by the teams is not giving him what he needs. The combined review with only Development Teams present reeks of a status meeting for your manager. Maybe it would be better for him to be invited to the individual team Sprint Reviews.  That is if there is no need for scaling. If you do have 3 or more teams working from a single Product Backlog, you might want to study up on the scaling frameworks and see if there are practices you can use from them to help your manager.

For C: As mentioned by above, trust him that his intentions are admirable.  Work with him to better understand his reasoning and help him find a solution that honors the individual teams ability to self-manage, provides the transparency needed by the rest of the organization and still honors the Scrum framework.

I would also question the value of reporting on the number of bugs. I read somewhere recently (perhaps Mike Cohn's blog) that the number of bugs can be taken two ways.

Does a high number of bugs indicate that the development is lower quality, or that the testing is thorough?

Does a low number of bugs indicate that the team is working together to fix issues as they arise (and not raising bugs), or that development quality is good, or that the testing is not thorough?