> And the meetings it takes to do Sprint planning, stand-ups, reviews, demos, retros are really killing any possibility of developers having a flow of uninterru

> And the meetings it takes to do Sprint planning, stand-ups, reviews, demos, retros are really killing any possibility of developers having a flow of uninterrupted time to do what they need to. This is because the Scrum "masters" are not masters of the domain. In most cases, they went to a two-week class to get "certified". They have no understanding of the development process and they are not accountable to developers at all, only to upper management to whom they sell the word "agile" as a project management approach. What they are doing with all the planning/prep all the time, of course, is playing mini-waterfall in 3-6 month horizons. > the real impact of that work is almost always never evaluated. Because that might actually lead to reflecting on the performance of mid-managers and the scrum "masters". These groups tend to view developers as assembly line workers, they still think the "size" of a PR is indicative of its importance (think the KLOC counters of yore), and they think "key person risk" can be mitigated by eliminating said key person instead of fostering an environment that open to knowledge/experience sharing. Those who can't do the tech get threatened by those who can and instead of focusing on their own comparative advantage and ensuring a productive environment, they focus on subjugating those who can do the tech to their every wish (fixating on things like label colors, prefixing every ticket with TAT, insisting that every ticket must be comprehensible to any random person in the company etc). When 30 hours in a week are taken up by mandatory meetings, they then penalize people for not spending 40 hours on development. I've seen places which required keeping timesheets with 15 minute resolution. I know there are places that are not like this, but I also know enough places that are.