This is my personal view on why Agile is the best flow for developers and their productivity. These are my own views and what and why I think certain things are better. All the points mentioned assume an agile environment.
Sprint Backlog to me is what cache is to CPU
I have found myself to work at my best when I have a clear set of tasks that I have to tackle for any given sprint. There is something... calming when I can see the whole sprint backlog at the start of the sprint. I'm able to plan the whole sprint duration properly.
This is, of course, the intended way of doing agile (at least that's what I think). Burndown charts can tell how many new tasks were added during a sprint, which is something we should avoid doing.
TL;DR: Devy dapper can dap best when all tasks are present in sprint backlog at the start of sprint. Last thing I want to hear is:
Oh client also needs this thing done ASAP too, adding in middle of sprint
or worse, in the middle of no sprint (no agile, very bad)
Estimate using anything but time
There's a reason we have found ourselves using fibonacci sequences and shirt sizes to estimate the complexity of a project, which indirectly gives a time estimate... indirectly. If we just wanted to go with time alone, we wouldn't need to stock pile shirts and random numbers.
Time can directly be useful for certain things, for example help desk. But it's not helpful for software development. In fact, it's harmful.
A developer's workflow is different from other forms of work. It's a creative process, where a small code change can require a long time of thinking, which is why we don't use time to estimate how long or complex a task is.
Forcing a developer to work 4 hours because that was the time estimate given will be frustrating as they'll constantly be looking at the time, no matter how much you say to them that the estimate doesn't matter. It's a new breed of micro-management.. subconscious.
TL;DR: Measure task estimate with dog breeds, bread sizes, anything but time.
Regular Sprints, no erratic work
Plan tasks for 2 weeks, start work, check at the end of 2nd week, repeat.
It's a very simple and easy to understand flow. It's a pattern that is very regular and not erratic.
Developing erratically i.e. jumping to developers and saying "we need this feature ASAP" is the worst way to manage a dev team. You might be able to get some quick work done out of them, but it will be hurtful in the long-run.
TL;DR: If your whole infrastructure didn't just go down, you don't need work done ASAP. Go with the sprint flow, and increase chances of delivering good work each sprint instead of unpredictable work with erratic sprints.
How to get this ideal world?
Any person that is interacting with both the client and dev team needs to listen to both sides and not just the client. Because that's where the ASAPs start coming and break the team down.
Ideally, the dev team needs to be isolated and protected by a product owner, or any person that stands in front of the developers to figure out what tasks should be completed in sprints and if they're possible.