If I was to explain the core objectives of agile software/product development (or agility) in three bullet points, I'd probably go for something like:
Glaring in its absence from these objectives is the idea of "getting more done", or "more with less", or "efficiency", yet the ability to do so is an extremely popular reason which many leaders in organisations give for "adopting agile" or "transforming ways of working".
While achieving more output often comes as a byproduct of agility, actually focusing on increasing throughput/velocity is AT ODDS with agility. Agile is about optimising for responsiveness and customer satisfaction over throughput. For effectiveness over efficiency.
In computer science, this friction and constant need for trade-off between responsiveness and throughput it called interrupt coalescing, and the concept is equally as relevant in the domain of scheduling in capacity constrained value-creation pursuits such as software product development.
To be clear — There's nothing inherently wrong with trying to "get more done". Improving processes by removing wasteful steps, limiting work-in-process, reducing context switching, forming cross-functional teams, synchronising dependencies, etc. enables you to increase the true available capacity of your existing people, and thus get more done. That might be a fruitful purpose, in certain contexts.
BUT — Please recognise that the pursuit of efficiency is NOT the same as agility, or agile. In fact it is in conflict. Agility requires paying very frequent attention to the customer's needs, and being ready to absorb changes in those needs into both the way you work and the work that you do. It is very easy to prove via simple simulations (and observing real life) that if you are paying 100% attention to work you are already doing — especially trying to churn out more of it — you will become unresponsive to the customer.
Among all the talk of agile, scrum, kanban, throughput, velocity and the like — Be very mindful about what you are optimising for.
And, please, call your improvement endeavours what they actually are. If you are trying to improve efficiency, call it that (and be explicit about the type of efficiency you are trying to improve — a post for another day, perhaps). Doing it under the guise of "agile" will send out mixed messages, confuse and upset people (regardless of their views or use — or not — of agile principles), and will not lead to the efficiency gains you crave.