Velocity is a great metric for the team to measure their current performance and by that, their relative success in applying continuous improvements.
Velocity is not a core Scrum element, it is complementary to Scrum and a product of estimating and tracking the effort done by the team. Estimations are under debate for a long time already, one of the reasons being that a team’s velocity is often misinterpreted by management and Product Owners as a key metric to drive performance, roadmaps and release schedules.
This incorrect usage of velocity will inevitably harm your Scrums empirical process control and turn into a self-fulfilling vanity metric, leading nowhere but towards disappointment. This is because the development team has full control over the effort estimation. Under the pressure of management expectations for stable or increasing velocities, the estimation is easily tweaked to match the expectations instead of revealing the reality of progress.
Scrum of Scrums
The Scrum of Scrums is a meeting I see in many organisations. Scrum Masters of various teams get together during the sprint to discuss progress and align on impediments. This is sub-optimal because the people who can best align on the work is the people that actually do the work. The process of aligning slows down and causes communication noise due to the hand-off from the developers to the Scrum master. The Scrum Master would provide better services to the teams by identifying the people who need to align or by facilitating the alignment session.