Reposting this from a post I made in another thread on bad Agile. Most of what I mention boils down to exactly what he is describing, if you have all the metrics set by people who not only don't know how to use the right metrics, but also have no idea what any of the metrics like story points or burndowns mean...

We (600+ person company) use Scrum as a way for our bosses, all the way up to the CTO, to utterly, hopelessly, absolutely micromanage every fucking aspect of our work. It's not really Scrum, it's just Agile software used to track insidious micromanagement. After a few years have gone by, I'll make some blog posts on "incredibly toxic agile antipatterns", but for now, here's a sample of the best rules of the "scrum as a micromanagement" model, and no, none of this is an exaggeration. All of these things are being practiced as we speak:

1. Every team must do Scrum. And every team must use the same soul draining software (Rally). That is a law of nature. We are a data science team. Some members (data scientists) are doing exploratory research and are better compared to university professors. Doesn't matter, use Scrum. Some of us are basically devops space janitors that keep the lights on for the scientists. Doesn't matter, use Scrum. The way in which you use Scrum (how you lay out user stories, tasking estimates, etc.) should all be standardized to allow executives to pit your graphs against other teams' graphs.
2. End of sprint demos should be talent shows. They should be done in a monolithic conference call for the pharaoh CTO, in which literally every team presents their demos. However, the CTO must make sure that every developer is productive, and so each team must have each person do a demo of their personal contribution. All other teams are required to stay for the whole 3+ hour thing. I call it the "talent show" approach because you have to go up there and tap dance, and hope that you aren't the shittiest tap dancer that sprint because now literally everyone knows. Also known as the "not faster than the bear" meetings.
3. Burndowns always have to close out. The main purpose of a burndown is to show that teams are following both parts of rule 1: use Scrum and use Rally. If your burndowns don't look good enough, then make a user story for "unplanned work" to keep it monotonically linear. If your burndowns don't look good, then everyone will know because every team sees the other teams' burndowns during the demo from rule 2. If it's not good, all the other teams watch you being chewed out for a bad burndown.
4. User stories' primary, no, exclusive, purpose is to show C-level executives what their developers are spending their time on. User stories should only belong to one person, and their purpose should be understandable by every executive, to include the CEO, COO, and CTO. If your user story is "widget X should allow users to specify the Y parameter on the Z model", then it's too fucking nerdy and the CEO won't understand. Doesn't matter if that's what the user or manager wanted. Make it "widget X should make better models".
5. Integrate (DDD) demo driven development into your agile processes as terribly as possible. If you as a CTO abso-fucking-lutely need a demo in 2 days for a customer that does things that won't be ready for a month, make sure to immediately set your underlings developers to the task of doing it. After all, we can't have our sales guys look like liars. But ultimately, you still need those features to actually work, so make sure that you lay into them because their burndowns look subpar.
6. Don't plan outside of sprints. That gets in the way of coming up with completely different goals and focuses each sprint. In fact, try not to let the teams themselves handle any of this. Don't designate ScrumMasters, just let the PMs do that. Did you think I meant Project Managers? No, of course I meant Product Managers. Because they are truly the ones whose ass is on the line, so they should have the authority to crack the whip. Last but not least, if you really need a product or feature several months earlier, just move the release date up. No plan, no rules.
7. Try to enforce arbitrary metrics on sprint results. You can't compare data scientists with web designers. Or can you? Rate the data scientists by the number of new models and algorithms they develop, and the web designers by the decrease in response time to their page loads. Doesn't matter that new models take a long time to make and evaluate, and that response times are bottlenecked by your disaster of a database. Hand wave those issues when brought up.
8. Finally, remember that at the end of the day, as a middle-to-upper manager, the sign of your success is a good burndown chart. That's what you're producing, so if the chart looks good, you've done your part. If your whole company shits the bed with the lights on for that quarter, then lean on rule 7 so that you can rank teams and lay the blame on the terrible developers you employ. "We only hire the best", but damned if we can figure out why these guys won't code faster. Maybe they're lazy? Make sure to compensate by moving some of the better devs from the successful teams (who must be overstaffed) to at-risk teams. If Brook's Law says "adding devs to a late project will make it later", it surely must have an inverse that "taking devs from a good project will make it better" to soften the blow.