Is Agile solving this problem now? or has Agile gotten out of fashion?
* release often, release early, each release should function though with less features.
* break large goal to small steps, one step at a time.
* sprint every 2 weeks or 4 weeks.
* 15-min stand-up every other day
* etc,etc
I read some agile books in the past, and now I'm experiencing real Agile in sw development for the first time, so far I found it is quite effective comparing to my past projects, assuming you have some great scrum master and project-owner that are really good at the balance of arts.
In my experience, if business stakeholders are seeing real value shipped to customers every week (or 2 if you must) then they don't get very antsy. Especially so if they are using a release-early, release-often approach to the product, where they see a project as an opportunity to explore what customers really want.
The problem starts to come in when the feedback loops are long. If they ask for something in January and don't see results in June, then they've got 6 months to wig out. And one of the ways they'll try to manage their fear is by getting up in developers' business by imposing all sorts of metrics.
First, Agile is a collection of ideas and principles, and not a monolithic thing.
Scrum (what you mostly describe) does not address this, really. Except that it attempts to reduce metrics down to a primary metric (there are others): Story Points. These are the primary concern of a Scrum team, and are developed by the team members as an estimate of the size of the stories (tasks) as they see them. These are not given by anyone else. These are not used by anyone else. The team then evaluates themselves (if they do this correctly) by constructing a control chart [0] to see how they're performing. If they trend down, they identify the cause and share the reason with other teams so that others with a similar cause can address it more readily. If they trend up, they identify the cause and share so that others can attempt to duplicate the success.
Scrum does not address how to do personnel performance evaluations so it doesn't stop management from trying to use metrics for the purposes described in this article. For example, story points (if used as an evaluation metric for personnel) become useless as people will just inflate their numbers in a continual game of oneupmanship. At which point a large amount of the value of Scrum is lost.
The Lean school of Agile is a philosophical descendant of Deming's work in Japan post WWII and the Toyota Production System (called Lean as it spread). This school of thought does address the issue discussed in the article in that Deming's views have you reducing your focus on individual performance and increasing focus on performance of teams and projects (title of the article is related to this). Deming and others recognize that the system in which work is performed effects the outcome more than the workers themselves (NB: His focus was largely on manufacturing, but this works in service industries and to some extent in our discipline as well). Since the view in that school is on the system, it does address the problems described in the article (if you get management to understand it). So by focusing on the project level (really you should probably go higher, department or even enterprise level) you can understand where problems are occurring, where there is waste worth cutting or addressing, etc.
That said, I do not recall seeing some of those points I made (gathered from Deming and other sources) in any of the books I've read on Lean as it relates to software. It could just be that I have forgotten or missed that information (may have glossed over it as I had already internalized it) or was in sources that I haven't read yet.