Is it really 'Team Agility' ?

Today, as enterprises continue to face increasing competition from freelancers and startups as increased cloud adoption is causing disruptive business opportunities and challenges for everyone. It is not surprising to see the enterprises going for more agile processes.
However, there is a world of difference between large enterprises and small units of tightly cohesive teams that are set out to achieve software agility. In a recent conference that I went to, this was echoed as 'culture' that no tool or technology could change - as it came from within. A lot of agile projects have not reached their promised outcome as the culture got in the way of their implementations. My personal observation is that apart from team culture, individual behavior and understanding has also got in no small way to do its part in making changes into the outcome. The culture is merely the result or the sum of individual behavior and as micro ecosystem influences the macro one, the individual behavior plays a compounding role in the business of being agile and at the end of the day delivering quality software.
I have worked across different teams during my experience as a software craftsman and the major part that facilitated output was not only the tools and automation in place, but also how the team got on together as a unit, without having egos and finger pointing out at one another. In a larger enterprise, that is rarely the case and my main point here is to reflect upon the team composition as in most projects, there is a management team that handles teams working across different timezones and also managing the bench strength. Unfortunately, this leaves a large room behind for miscommunication which is resolved through process aka documentation that kind of defeats the purpose of being agile in the first place.
What is needed is to have small teams that are oriented towards individual results rather than team efforts(this might be contradictory to the management version of a team but will lead to transparency) instead of large monolithic units ('Lines of Businesses' as they are called) and have cross-functional lines of management between them (to facilitate agility in different sprints) instead of being top-heavy. It is easy by major software tool providers to sell tools to add in agile processes, DevOps, automation, etc. but at the end of the day these are just some buzzwords that probably make your client satisfied about the agility and the appearance of a leaner process when apparently there isn't any.
So instead of merely claiming to have a startup culture, both the software providers as well as clients need to own up to the fact that to have a faster and a cheaper software delivery model, the team size and work needs to be more transparent rather than process heavy which allows for both incidental and malicious efforts to cause inefficiency.