Dysfunctional agile teams have often been blamed that their lack of productivity is because "they are not doing true agile".
Most places me and my peers have worked, feature 'agile' but also 90 minute scrums, rigid processes, ban on any communication beyond "Done, Next, Blockers".
Which of those are in breach of the agile mindset? How pure does a process need to be to be called 'an agile methodology'?
The "true Agile" you probably have in mind doesn't exist. Some teams are more Agile than others, some are less. For a bunch of other teams Agile is just a buzzword which doesn't reflect in their practices. Some even refuse to use the word Agile and prefer to say "move with agility", to detach themselves from the buzzword.
Agile is a set of values and principles. It's a mindset for building software where you keep the client close, you use communication, collaboration, inspection and adaption, and self-organization to iteratively and incrementally build working software.
It's also an umbrella term for other practices: Scrum, XP, Kanban, Lean, etc. And in this context you can rephrase the question and ask which of these practices is more Agile? Is XP more Agile than Scrum? Is Kanban more agile than XP?
Agile is also an industry that ended up in many instances as something that put aside the values and replaced it with a money making machine. You get sold Agile books, Agile conferences, Agile trainings, Agile workshops, Agile retreats, and Agile certifications. Then you can also ask yourself if a Scrum Master with a certification is a better Scrum Master?
But even if you can't precisely define Agile, you can use its values and principles to look at what you are doing and see if you are making use of the idea of Agile on some lower or higher level. 90 minute daily scrums, rigid processes, or ban on any communication beyond "Done, Next, Blockers" are clear indications that things aren't Agile. Since you mentioned 90 minute scrums, I'll assume you are doing Scrum, so read the Scrum Guide carefully and see which of its guidelines and rules you can check of and which you can't. In the end, at least you will know if you are doing Scrum or not as described in the guide and only later think of how you can make your Scrum implementation more Agile.
If you are regularly holding long meetings, then it is fair to say that your organization is not reaping the benefits of Agile thinking. Certainly, a daily retrospective, which is a common mindfulness activity used in many Agile settings, should really be a "standup" most, if not all of the time.
But, some things do require time - User Story Mapping at the start of a project, or figuring out how to start a new product come to mind, and that can involve meeting over several days. Likewise, an Agile Backlog Grooming session can easily be an hour (although I would hesitate to allocate more time, barring unusual circumstances, nor to do this more than, say, once a week - depending on where the team is and what needs to be done), the Demo and Retrospective at the end of a Scrum sprints, and/or SAFe PI (program increment) likewise can be longer.
Those are the exceptions. Part of an Agile mindset is the ability to keep meetings short and focused, except where you need specific people (rarely the whole team, and often involving "subject matter experts" (SMEs) from other groups) to address specific problems.
"True" agile smacks of faith healing. A better question might focus on whether or not the teams have the freedom to self-organize and find ways to prioritize and complete User Stories in ways that work for the organization. Long meetings that involve the whole team are unlikely to be part of that, but let the needs of the team decide.
Agile is defined by the values and principles laid out in the Manifesto for Agile Software Development. There's no such thing as "an Agile methodology". When the Manifesto was created, it was an abstraction layer over a number of methods, including Scrum, Extreme Programming, DSDM, Crystal, and Adaptive Software Development, to name a few. The Manifesto was the common ground between these various methodologies.
Very few practices are mandated as part of the Manifesto. In fact, there is only one: continuous improvement of the way of working. The other values and principles can help a team choose or develop practices, but there aren't any practices mandated in order to be agile. Different frameworks may require certain practices or put rules on structure beyond those in the Manifesto, but those are requirements of the framework and not Agile.
Looking at the three things identified in the question ("90 minute Scrums", "rigid processes", and "ban on any communication beyond 'Done, Next, Blocker'"), only two are inherently against the values and principles laid out in the Manifesto - the rigid processes and restricted communication.
One of the values of Agile Software Development is "individuals and interactions over processes and tools". The last principle involves reflecting on and improving the processes used by the team. If the emphasis is on the processes and they are rigid enough to not allow for continuous improvement, I would consider that to be inconsistent with Agile Software Development.
Limited communication also goes against the value of "individuals and interactions over processes and tools", but a number of underlying principles such as stakeholders working together throughout the effort and self-organizing teams. Communication is a cornerstone of collaboration, information sharing, organization, and even trust.
Long Daily Scrums or stand-ups aren't against any of the values and principles of Agile Software Development, but they do go against the rules of Scrum (if you are choosing to use Scrum as your framework). In fact, if the team is choosing to have them, one could make an argument that it's a side-effect of self-organizing teams. However, it does depend on the context and there is probably a better way of working that can reduce the time in the meetings and increase the time that the team spends on delivering a working product.
To me, "Agile" and the various other "methodologies" are "good ideas." They are "good" in the sense that many teams have found them to be useful and beneficial – creating more-effective cooperation within a team and better communication with the business stakeholders. But, they are not Holy Scripture.
Sometimes, a meeting does have to be "long." Sometimes the guidelines that are spelled-out in this or that "manifesto" do align with what your team is doing, and sometimes they do not. Pick-and-choose the best ideas that work for you, and don't sweat the rest. As Perl programmers like to say: "There's More Than One Way To Do It.™"
There is no "agile methodology". The Agile Manifesto encourages teams to self-organize, collaborate and be adaptive whereas your description of a rigid, uncommunicative process with long meetings means that those agile ideas are not being put into practice. Don't look for textbook answers to those kinds of problem. The solution is to find the right people to help your team(s) improve their ways of working.
