I stopped half assing different work during useless meetings long time ago. Now I shamelessly slack off during those meetings. Most of them only exist so managers don't have to do their work alone, they prefer 30 developers watching them while they do it.
Part of the problem is that the roles of people in meetings are often at cross purposes; the role of managers, scrum masters, and other coordinating staff is to ensure communication so that engineering staff can implement whats wanted, and the role of the engineering staff is to implement. This means that coordinating staff are trying to maximise communication, because that's what they're there for, but the engineering staff are trying to minimise communication, because it eats into time spent problem solving. This is why the Agile Manifesto encouraged developers to work directly with the business - it reduces communication overheads, affording developers more time to tackle the problems at hand. And the idea of maximising work not done also applies to communication work: communicate with the people who know the problem to find out what needs to be done, but once you have an idea clear enough tackle and bring back, then it's time to implement.
Given the change in our industry in the past 20+ years, I think we use the term "Product", "PO" or "Product Engineering" instead of "Business". If you read the whole context of the 12 Principles and 4 assertions, you find a very strong leaning toward Continuous XYZ, Demo'ing and interacting with Customers (not business), and a very strong sense of Autonomy Away From the business. Again, the literal line "Business people and developers must work together" today would be translated as the Product Team, QA (who were considered business back then), and Developers. But it can't be said enough that the overall sense of the Agile Manifesto leans VERY heavily toward Autonomy. Especially that [The Business] should "Give [Devs] the environment and support they need, and trust them to get the job done."
One of my upcoming engagements will be speaking about the difference between management and engineering leadership. A huge point is how there is an absolutely black and white difference in "the strategy" when you talk about the Product Engineering versus the "Business Strategy". Business strategy conflates the product with things like morale, customer satisfaction, governmental compliance, UX research, etc. These things should leak into Product Planning, but there are massive amounts of discussion and data that needs to be hashed out prior to the "Product People" beginning their direct collaboration with their fellow Amigos (see 3 amigos or cross-functional). The problem is that management doesn't know where the line is, so they pull everybody into every meeting. Or, that the Product Team isn't up to the task of working both sides and finding out where collaboration needs to happen. Business people need Meetings. Engineers need small, constant, ongoing, collaborative discussion.
