Yet agile implemented top-down without team ownership of what to work on is not agile and not good for the health of the codebase. I have seen it fail repeatedly.
Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.
So if you're behind schedule, your team just isn't skilled enough? That's kind of a dodge. Every team can improve.
Instead of exclusively focusing on finding "good" developers, let's also focus on evolving "good" process. Time tracking, estimates, itemizing tasks.. these are in fact good things.
I would, and have, argue that estimates and time tracking are, in general, wasted effort.
If you have good priorities, estimates are irrelevant, because you'll be working on the most important things, and that is unlikely to change no matter the estimated effort. If you don't have estimates, then you don't need time tracking to see if your estimates are correct.
You've just eliminated half of the overhead for software development - the only added cost is that you must continually understand and update your priorities (or values, if you prefer), which you should be doing anyway.
Basically, if your team is skilled and capable, the process is not that important, as they will find a way to get things done. If the team is not good, the process won't make them much better. The key to a smoothly performing software dev team is good hiring and good coaching.