You heard it here first, kids. There is a new buzzword in town, and it's name is dogmagile™️.
Dogmagile™️ is defined as: the set of practices and procedures which are conducted as a means to impose arbitrary metrics on output while being inscrutable to measurement themselves. Also dashboards about ticket output...
An litmus test of being inscrutable while scrutinizing is the question "is X agile framework working?". I have experience with this question being asked. What surprised me is nobody knew if it was working or not. Some said "we're just not doing X agile framework right..." and if we did X agile framework "right" our problems would go away. Some said X agile framework was the problem. Some said it was the sprint lengths. Some said it was the way tickets were being handled between two systems... and on... and on...
X agile framework in this example is "scrum". Scrum as a dogmagile sect due to its inscrutability.
It is easy for me to pick on scrum here, given it is what I've been exposed to the most. Most, if not all, "agile frameworks" or "agile methodologies" are dogmagile sects. The "one true" productivity system to reign in the demons of difficult and bespoke software development.
Look at the Agile Manifesto. Look at the authors/signatories. What do you see?
And since it is the Christmas season... "Do you see what I see...?" Man, that song is banger. Moving on...
I see out of the 14 signatories, 13 of them are consultants. Such a fact is critical context, often ignored. In my experience consultants are effective in either building a solution from the ground up, or saving a project. Onboarding consultants onto projects which are at the very least doing okay tend to cause mixed results.
In the former case (building from the ground up), consultants are accountable to non-technical partners who fundamentally don't understand why computing and distributed systems are difficult. And usually non-technical partners would like it done yesterday.
In the latter case (saving a project), the development team has eroded trust with the business folks (née non-technical) and need to show their value out of the gate and at "touch points". A consultants value is to show the team moving toward the goal post, not the goal post moving. As usual, non-technical partners would like it done yesterday.
So how does the agile manifesto fit into the above two scenarios? It intentionally doesn't.
What has been coined as "agile software development" nowadays isn't actually software development. It is a set of practices to give management (née usually non-technical folks) a set of tools and processes to reasonably hold accountable (née fire) individuals or teams based off arbitrary metrics. Accountability isn't bad, arbitrary accountability is.
In the "building from the ground up" case and the "saving the project case", non-technical partners need to be "kept in the loop" to "ensure we're on track". Usually, from my lived experience, communicating "we're doing X well, and Y not well, we don't know about Z" doesn't satisfiy the powers at be. The powers at be, want to be able to lookat (i.e. mis-interpret) graphs or have someone else do so and tell them "the project is it going well" or "the project is not going well, these are the people to let go". Usually, the former is correlated with some sort of bonus, the latter with some sort of bonus, scapegoating, and damage control.
Not enough tickets on the dashboard for the last quarter: engineer(s) fired, at the very least PIP'ed.
Velocity down: scrum master re-assigned to another team.
Backlog has "too many tickets": product owner scolded for making skip-level look inefficient.
Sprint carry-over to high: manager scolded for cultivating "lazy developers".
And on... and on...
I even heard once (gross paraphrase) that "a team should shoot for 80% done each sprint... it signals we're not being 'soft' and coasting, but being productive enough". What that signals to me is the management chain has a shallow understanding of what it takes to produce beneficial software, and it is a "damned if you do, damned if you don't" proposition. Do you want to be seen as "ineffective" in the 80% or "coasting" as in the everything is done by Thursday? Damned if you do get your planned work done, as you'll be seen as "not doing enough". Damned if you don't get your work done, as "why is your team always underperforming".
It is a silly game. It is a game to make engineers less powerful in an organization, because they're always guessing about where that goldilocks zone is.
Again, the above has nothing to do with agile per the manifesto. It has to do with everything adjacent calling itself "agile" when it is really a wolf in sheeps clothing.
Dogmagile™️ needs to die a heat death. What is it to be replaced with?
Context aware practices which are in and of themselves adaptive to what is/isn't working. My advice is to start by shipping software and see where communication breaks down, quality suffers, trust is eroding, etc... Understanding your context will inform how to address foundaitonal problems rather than adopting a foundational problem (i.e. dogmagile™️ practice) out of the gate. Doing so involves critical thinking and uncomfortable conversations. If critical thinking and uncomfortable conversations are too much for you, the door is over there.
In sum, agile ruined a lot of really intelligent, well meaning people to be over concerned about useless metrics, dashboards, and visualizations in the name of "efficiency" and "quality". Really? There is nothing efficient nor quality producing about dogmagile™️ practices today. In fact, they encourage waste either via meetings, retros, standups, etc...The incentives aren't delivery of quality software which is a benefit to humanity. The incentives are looking like you're delivering quality software with heaps and mounds of context unaware processes, practices, and tools to give managment chains power over their percieved greatest liability: people.