Yeah, you nailed it. I have seen this done so poorly so many times that I simply tell people to rotate the ScrumMaster role. Otherwise they just make it into a manager.

A lot of times they want to keep the old Project Manager around, and that's very difficult to do. Project Managers and ScrumMasters are completely different animals. A few times as a coach I have literally thrown the PM out of the stand-ups and told them not to come back because they were turning it into a status meeting.

I'm not trying to plug coaching, but if you're trying Agile, you really need an independent outsider to help referee stuff like this. Maybe it's only the SM from the team down the hall, but stuff like broken standups can be impossible to fix without a little neutral nudging.

Exactly. It was amazing how quickly, at my last place, standups devolved from

...recounting verbally what one did the previous day...

...to marking one's progress on a whiteboard...

...to having to write down on an index card beforehand and turning it in to the IT director after the scrum meeting (in addition to the above).

With the boss (and sometimes, the CEO) in attendance, there was no chance of an honest verbal exchange about roadblocks etc.

Good metrics for measuring coding progress are so elusive, I can't imagine management NOT trying to mess with pure agile principles if tight deadlines and delivery dates are at stake.

Unfortunately, I got Scrum going at a small, chaotic, mismanaged consulting shop I worked for after using it at my previous job with reasonably positive results. Management loved it because it fed their natural micromanaging attitudes (e.g., employees are basically lazy children, will not work unless coerced, and must observe strict deadlines). I realized all too late that I was contributing to that.

These days they only do the daily stand-up, which is of no value to anyone except my former manager, since people talk directly to the manager and not to each other (this is one of many reasons why managers should not be in stand-ups). It became exactly what you said: a daily mini performance review.

I've since realized that the things that make Scrum successful are the same things that make a team successful, and that you can't necessarily connect a causal line between Scrum and team success if the team would have probably been successful anyway. It basically comes down to the team having a good rapport--regular communication between team members, the ability to seek advice without judgment, and the ability to communicate blocking issues in a timely way to the right people.

I think this kind of weird misinterpretation of the buzzwords happens because most people don't actually read anything about agile. They just hear other people say they need to be doing "daily stand-up meetings", and they interpret what they think that means, instead of bothering to find out.

I had a wonderful example of this behavioral pattern last week. I was called into my project's first "sprint planning meeting" where I was asked to write down for the next 8 sprints which features would be delivered when. Of course, since we were now "doing agile" I was allowed to be off by one or two features every sprint. But it still had to all fit into 8 sprints, because the project's deadline was by the end of the 8th sprint, and we needed to be sure we would deliver the full scope by then. As pepe le pew so aptly described: "le sigh".