This hits home like a brick, and I'm not sure if it even has a solution. In my experience, many scrum masters tend to just fill voids. If there isn't a projec

This hits home like a brick, and I'm not sure if it even has a solution. In my experience, many scrum masters tend to just fill voids. If there isn't a project manager, the scrum master sometimes may take in that role, calculating "velocities" and pushing plans according to timings. If there isn't a proper team lead, some scrum masters would organise and assign work. If there is no product owner, or the product owner is absent, some scrum masters prioritise functionality as they see fit. Perhaps the most blatant "void" that scrum masters tend to fill is teams willingness to participate in agile. As far as I understand, teams must agree to the kind of "bureaucracy" that needs to be done in each iteration. In my experience, some scrum masters step in and set the "sprint rules", which may or may not be challenged later. But in the meantime, we get demos, and retrospectives, and planning, and tasking, all by default. This is a bit like a "when all you have is a hammer, everything looks like a nail" situation. Because all the work scrum masters do is predicated on teams being agile, then imposing agile by default is the way to go. Thus I try not to blame scrum masters for these thoughts, even though I know that the main argument against these practices is that they may be "anti-agile". In fact, I see these real life examples of applied agile as the best argument against agile itself. And maybe the issue is not that people don't know how to work with agile, just that agile is not very well suited for people.