I read this in the article, and had to wonder what on earth it had to do with making things:

If you are the scrum master, keep doing what you are doing. Keep coaching the development team on our core values of openness, commitment, focus, respect, and courage.

The scrum masters I have seen (including myself) turned quickly into bureaucrats that mainly managed deadlines. In theory the scrum master should constantly improve processes but from what I have seen they quickly get blocked by management and don't achieve much.

I jokingly called my last scrum master a "glorified assistant", he didn't like it.

You start out with great intentions but then you realize quickly that you have no authority at all. We had problems with our JIRA setup so I tried to buy a few hours with a consultant to set it up correctly. This request got declined so it was clear to the devs that I couldn't help with things. The only thing you have is tracking hours.

I've had the most conflict with team members who think "making things" is an end unto itself. Sometimes it is -- in your personal time, or if you're a researcher maybe, etc -- but in a business, making things is the means to an end. You need a methodology (scrum or something else) to keep the machine moving.

I'm still not sure how a manifesto with "Individuals and interactions over processes and tools" ended up as the scrum cult.

Huh, by-the-book scrum is the opposite of micromanagement.

That kind of scrum is a pretty elusive beast. I have never seen it.

I guess it depends on what you think micromanagement is. I know devs who think "you can work on any item in this list of things but no others" is micromanagement.

To a micromanager, everything is a micromanagement tool.

You can't use methodology (or a pointed lack thereof) to change personality.

Sure you can: the methodology is to not hire them in roles they can micromanage.

That's management methodology, not programming methodology.