> when in your next sentence you admit that a week task has taken you more than a month
The word 'admit' suggests you had to drag it out of him, that he's hiding slow progress behind a smoke screen of busy work like opening many tickets. That month-long background task wouldn't have had any work done otherwise so it's unfair to call it delayed.
> Until you adopt my old-fashioned approach of single threaded work
That's the problem with people who think they're technical managing the actual workers, they always end up micromanaging and slicing things into shapes that don't fit. The world isn't single threaded and changes usually aren't entirely unrelated.
You should change your management style to simply specifying the business goals you want and asking for as many to be completed as possible. Let your team do what works best.
> The funny thing is you probably consider your approach agile
No, because all those labels just encourage people to pick a style and do that thing regardless of circumstances. In a real project I've got to coordinate everything with someone. I can't push code without a review, I can't code to a team's API without sending them the spec for review, etc. During these times I could facebook like some others do, but instead I "multi-task" by doing other work.
Also, it's not very obvious from simple metrics like number of lines of code committed which work is hard and which is simple fluff which can be fixed without a distraction. A change to a logger might percolate through every method call and appear big and complex despite having been made in seconds by the IDE. If I was implementing a new feature I'd probably want to update the logging style first rather than coding to the old standard, so I'd make the big change (probably covered by another ticket) because I'm already in there and have to test that stuff anyways.
> There's no value until you finish, and I mean done-done.
As I said, there are a lot of down periods in that process. It feels like you think you know some deep secret ("only delivered features count!") that you think you can't get people to acknowledge.
This is actually like day-one stuff in engineering school, that you need to measure benefit of your work in delivered advantages so done isn't done until it's in use. But there's a lot of other stuff as well, such as not delivering something until it's safe to use even if it works in test scenarios.
You should have a discussion with your team about your idea and brainstorm where it fits into a full product development cycle and what has to be considered. I imagine you will find they don't discount it, but they have a wider view of the process than your business focused one, and that they have to balance all of this while also managing your perceptions.