Agile Scalability is essentially of Being Agile, not just Doing Agile.
From techopedia: Scalable agile is an agile software development process that refers to the ability to manage large projects with multiple teams. Based on its conceptual framework, agile software development is often considered to not be scalable and only intended for small projects and teams. Thus, Agile's scalability is a heated and debated subject. Many believe that agile development cannot be sustained when a project is large or multiple teams are involved. The flipside is that many open-source projects could be considered loosely agile given the iterative nature. So what are further perspectives upon Agile scalability?
The agile processes are scalable when they take into account architectural changes. In other words, the project team cannot make decisions in isolation but has to take into consideration the concerns of other organizational units. But it is also paradoxical: On the one hand the agile methodology says: you need to be agile, it should be possible to change everything to fit the customer needs. On the other hand architecture says: Architecture is about everything costly to change. It does not say agile and architecture is not compatible at all; it does mean that the large development organization should not focus on agile techniques, but on the system architecture and the teams may use what ever is reasonable and applicable for them.
It takes systematic way to find out which decisions have the most impact in a particular business domain and addresses the scalability cohesively. Business goals, core requirements/constraints, the architecture - all of them have the same nature - it's about human decisions. And the trick is to find minimal number with the biggest impact and to make these decisions first (it becomes the vision, the guidelines, basis for the organization structure etc.), and that challenge is what makes companies successful, or not. The huge rest of decision may be and should be made later.That means agile scalability is not just about doing Agile at large scope, but about being agile at the heart of organization.
When it comes to agile projects at scale, metrics are there to provide insight as well as visibility. They are there to help gauge whether the team is in trouble, the products being generated are of sufficient quality for release, the process is working and, most importantly, the team is on track and that value will be delivered to the user or customer who should be, but often isn't fully engaged in the development. The metrics can be of three kinds (at least) - project, quality, business value
The even larger issue is effective governance. You can gather the best measures in the world, but if the people looking at them don't understand the implications of what they're looking at and then act appropriately, you have a serious problem. There are plenty of metrics, that people misunderstand and misuse them and that proven metrics frameworks provide lots of insight. An effective governance framework, process and metric can ensure agile scalability sustainable and measurable, and to track and gain visibility into progress at the project and enterprise levels.