Agility as a mindset over methods and terminology
Stories, story points, acceptance criteria, stand-up, sprint, retrospective … Keep going, you will soon cover several key terms of modern software development. However, you may find that agility as a mindset is missing in this busyness of daily actvity — product development.
Another title of this post could have been: 'Avoid Agile Industrial Complex.'
Mind you, I have nothing against agile ceremonies or the terminology. For anyone doing software development, I urge them to start with Agile Manifesto (see below) and use it as an ongoing reference. For example, check whether we're connecting as individuals and having rich interactions or am I using a tool (e.g.: Jira) as a proxy? Jira or any other tool has its place, but know the distinction.
Know activities vs. outcomes
When you start with these principles above, your focus shifts (rightly so!) to how best you can create the software iteratively. Build the smallest possible viable thing. Then, showcase it quickly and verify its usefulness. Repeat.
Everything else is busy work that exhausts you so much but with little to show. You may have ten features and seventy story points of accomplishment. That, however, does not answer "so what?" question. Using "so what?" is a great way to check yourself when you say I have accomplished 'X.' So, simply moving a story from one lane to another does not count — answer it in terms of "what is the benefit of it?"
If you can see the distinction between the tooling (agile ceremonies, jira, etc.) and agility (the mindset), you can not only utilize the tooling as a means but also excel at accomplishing your business outcomes.
In closing, I urge you to take a couple of steps back to gain a better perspective. And, always ask what is the purpose of this busy activity. Rephrase the goal in terms of customer, business, or infrastructure.
(Well, let’s not get into SAFe discussion. It’s a topic for a different day.)