The worst part is the non-linear growth in productivity of uninterrupted blocks of work. Not always, but very often a 4h block is much more valuable than 2 bloc

The worst part is the non-linear growth in productivity of uninterrupted blocks of work. Not always, but very often a 4h block is much more valuable than 2 blocks of 2h with a meeting in between. This is not even about "flow", it's about getting your work environment sorted out, getting all the tools ready, doing a couple of experiments, actually thinking about the context of your solution, etc. It's a very costly fallacy that developer productivity is simply linearly dependent on time spent on an issue. In consequence, I strongly believe that there should be a minimum latency in software development that cannot be cut further. Say, it's two days. That would mean you should not attempt to have any meetings from Wednesday onwards and be able to deploy on Thursday evenings and collect and discuss results on Fridays. Monday's for retros, especially regarding Friday's findings and Tuesday is the day for planning. That's a very, very compact schedule and I doubt it's sustainable, to be honest. But it's already longer, and has stricter constraints, than most managers would accept, I bet.