Agile done right is all about less process. It’s right there on the Agile Manifesto:
> Individuals and interactions over processes and tools
I’d also read https://agilemanifesto.org/principles.html for an illustration of what is considered valuable — especially the bit about simplicity which process heavy (aka fake-agile) agile consultants totally miss; also the bits about what constitutes project progress & how to most efficiently convey information.
You should be able to tailor your agile processes to what makes sense for you. Following the herd and insisting on agile ceremonies “because everyone else does it / someone told us to”, even to your team’s detriment, is cargo-culting.
In your case you clearly tailored your process to something that improved your efficiency and met your reporting requirements, so, as far as I’m concerned, you’re doing agile “right”.
I get the sense the authors of agile used words like “scrum” because they imagine software development like a full contact sport; where everyone is fully engaged with all their senses to truly be aware of what’s happening, what’s needed and what is the most important thing to work on. The cargo culting agile consultant approach always feels like an attempt to make software into a repeatable assembly line, and make software engineers into factory workers.
FWIW, shitty agile consultants have had plenty of pushback too, with comedy sites like https://www.halfarsedagilemanifesto.org/ being set up to point out their buffoonery. I do suggest laughing in their faces when they pull out tripe like that. Sometimes their excuse is, 'well, we don't work for a startup, we're a regulated business' -- well, it's still tripe, there are plenty of regulated businesses with lightweight agile processes.
My favourite piece of writing on this, in fact, comes from the US Defense Innovation Board, and is called "Detecting Agile BS"[1]. Their recommendations may not 100% work for your organization, and that's okay -- tailor it with an eye to outcomes for your team.
[1] https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB...
I'm familiar with using Jira for enough customer support requests to require a full time ticket wrangler position, and closing tickets timely with accurate reports is often more important than the requested fix or support intervention: looking good with the IT managers that are, for all practical purposes, our customers has a higher priority, for everybody, than helping a random end user with a noncritical problem.
We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and we can do task estimation as a team and assign them, and so on. But most of them were tasks that would take a few minutes at most. (Some of the problems I fixed live while working with the designer). Our launch deadline was fast approaching and it would have taken more time to write a good jira ticket than it would to fix most of the issues - let alone discussing them as a group to estimate. While arguing he ended up showing his cards by admitting that the main reason he wanted everything in jira was for reporting. How else would upper management know that we were making progress? I said that sounded like his job, not mine. And he begrudgingly agreed and took my plain text list and dutifully retyped everything one by one into jira tickets. And then marked them all complete a week later when I’d fixed them all.
I think that experience killed the last bit of respect I had for Agile as a methodology - at least as it’s practiced in the wild. If we were using something lighter - like trello - I don’t think I would have resisted so much.