I'm probably preaching to the choir here for most of this, but here we are about 15 years after I learned about "agile development" and I've yet to experience a real agile environment even though everyone says they "do agile." Perhaps that's the problem, if you say you "do agile" then you've at a minimum misunderstood the assignment and at worst case are actively hindering your group from being truly agile.
If we look to dictionary.com we will get a definition of the adjective "agile", generally meaning to be quick and well-coordinated or active and lively. This word and definition has been co-opted in the software development world by the noun "Agile" which has been defined by Agile Alliance, Atlassian, and others as a set of frameworks and practices for software development, generally guided by a set of regular events and more that focus more on planning and processes than the productivity of the team.
Under the set of "Agile" falls different terms like Scrum, Kanban, and Extreme Programming. Each one of these prescribes a different set of processes for accomplishing the same work, but it also is attempting to put more structure in an area that purposefully wanted less processes, usually so someone elsewhere can put a number to the work that's being done.
When talking about Scrum, we talk about things like the Events, Retrospectives, Demos, and Sprints. None of these in isolation are bad things, however they can quickly add up to take half or more time in a given Sprint which bring the question of when do team members get a chance to be productive and build the thing. I've seen plenty of teams over my career do the daily check-in wholly incorrectly, to the point where a single team has a half or whole hour check-in daily, which wastes an eighth of the day for a dozen or so people. Sprints are also an interesting name for the given time-box for a chunk of work. I'm not sure about you, but I can't sprint physically for too long of a time. Here we are telling our teams that you have to sprint, essentially forever. Scrum doesn't bring up mental burnout nor does it discuss having breaks, it only discusses how to "keep moving forward" 100% of the time, damn the real consequences of that. Maybe your team/business has natural downtime to upskill, learn, or not sprint and for that I commend you, but I've seen that as the exception and not the rule. I've also yet to see or work in a team where they can even remotely closely estimate the size of tasks so that the team doesn't overburden themselves for the Sprint. When this gets close, at best someone from outside of the team wants more done and will bring things into the Sprint without taking things out, thereby losing the purpose of empirically selecting the amount of work based on past behavior. Another quite alarming thing I've seen is the push for teams to outdo each other by claiming more average story points than another team and even worse, judging performance based on the number of points and continually asking for that to go up year-over-year.
Kanban has been my preferred method when working in "Agile" environments, primarily because it forces us to be aware of the next most important thing to do. This also keeps business requirements or "stories" to be a whole thing or thought, or have the infrastructure available to feature flag new development until the entire thing is ready to go. Typically I've seen this combined with regular check-ins, retrospectives, and demos, but it can naturally allow the team space to breathe because they're not necessarily focusing on finishing multiple work items by a certain sprint-end date. Some may say that without hard deadlines that developers will take as long as they want, but I never said there couldn't be deadlines, but that they are story-based instead of arbitrary because of a previously agreed upon standard cadence.
Now I can hear the "Agile" professionals out there saying, "Ted, you have no idea what you're talking about" and to you I'll say that I've been in your shoes and have believed that what I learned in the classes for Certified Scrum Master and Certified Scrum Product Owner were the correct things to do and tried to implement them within my teams. The first thing I'll say is that there is no one size fits all approach to teamwork and knowledge work and to believe that there is shows how little you understand the work your teams do.
If we go back to the original coining of the noun "Agile" and the (https://agilemanifesto.org/)[Agile Manifesto], it is easy to see where we've went wrong. Of course, by preferring the things on the left, we want them more than those on the right, but the things on the right are still valuable. If we look into the business of "Agile", we can easily see how much it goes against the manifesto because they prefer the things on the right by how they prescribe things to be done. Digging into the principles set out by the same group, I can see where the connections between "Agile" and the original intentions have been made. Nothing here talks about the productivity of the team or how business and technology can or should work together, nor the "people problems" that occur when you join groups of people that have differing minds and ways of thinking.
The first of a couple of the most concerning things I see in "Agile" today is around this principle, "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." I've already talked about this a bit further up in this post, but a concerning trend I've seen and heard is from others in the industry is the trend towards always being asked to do more with less and keep that trend going. This goes directly against this principle and I believe is the cause for a lot of burnout and general disinterest in the work being done. Another one, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Every team I've been part of has held somewhat regular retrospectives to learn where the pain points are and discuss what we should do in the future, but I've yet to see any of them effectively enact the change. Some individuals are better than others at enacting change, but overall if the team doesn't want to change then the change won't happen. This is even worse in larger organizations where the weight of the culture in that organization prevent any attempt at change and instead things are dictated from the top down.
Now, I don't agree 100% with the thoughts written down in the Agile Manifesto or their Principles and our world has grown and changed a lot since they were originally written. We now have stable video calls which can help supplement face-to-face communication for example. For the time though, they were and still are a good base to start. In today's age though, I believe the most important thing is adapting to what the team wants and needs most. This means being humans first and workers second. A team that works well together can communicate and understand each other, has their basic needs met around tools and skills to do the work, and has motivation to do the work.
The best agile teams that I've seen and worked with have been the ones that truly understand the context of the work they have and are supported with the tools and trust to do the job. As leaders in our organizations, we have to push for these things to allow those working with us to work effectively and finally LISTEN to the team and anticipate their needs. I believe if we do this, we can be truly agile in the sense that we can adapt to the needs of the business, build the right things, and build them right.