Actually, however, I'll leave ANT to you to follow-up on. One of the early ANT papers is quoted in Eight to Late, although it's a little dated, having been written in the old timer's era of 2001 about things that happened in the 20th century. Obviously, no mention Agile. Nevertheless, late 20th century is also the time when use cases were getting good play, so even though they are not mentioned, one can see the thought synergy.
My interest is in a quote in that reference paper picked up in ETL's post:
They (project managers) either take a Machiavellian view or promote superficial agreement and high sounding concepts while secretly working to their own goals, or they insist on all players subscribing to detailed design specifications expressed in the language of some dominant discourse.
Good grief! So PM's are either cunning and duplicitous, or we torture sponsors and stakeholders into agreeing to words, specifications, and documents they couldn't understand even if they read them.
My experience is that few of us are Machiavellian, but the other charge is too often true. On an ERP engagement I was struck by the futility of the methodology of our engagement partner to get stakeholders to 'sign off on' all the project design documents, as if they could read them (they were in English, but barely so), and more importantly thread them together into a narrative that made business sense.
After all, they (stakeholders/sponsors) were the guardians of the business value; we were the guardians of the earnable value. Our job--not theirs--was to make the translation from our domain to theirs--not the other way 'round. And, that was not the only project where I observed this ineffective sign-off practice. I never understood the value of a signature on a document that I knew was perfunctory and unrepresentative of what it was supposed to stand for.
So, whereas I don't buy the whole quotation (above), I certainly buy half of it! At least agile poses a more effective practice vis a vis the customer/user, even if the close proximity of the customer/user is problematic in many instances.
Bookmark this on Delicious