Looking Good
The project was recently reviewed by our funding source. This meant a day sitting around in once grand hotel rooms, and intermittently being questioned.
This ordeal had at least one positive result, leaving the steering board members with a real sense of solidarity. Better than playing paintball. For the first time, I got a sense that they are confident in me as project manager.
There were several probing questions about how well we listen to users. One particularly good one was "Name a feature of the current release that was specifically requested by a user". By 5pm they were satisfied with the answers.
The next day was a conference with the developers and users present. There was a session on the software product, and over my objections this had a demo not by the developers but by the a user. It turned out that the theme of the demo was how hard it is to use.
All very useful feedback, but the administrator from the funders was in the room, and still writing up his report from the previous day. So I had to take steps to make clear that we have two user communities. One has communicated well with us and is happy with the product. The other has not communicated so well, and does not like what it has.
One thing that made it worse was that the project plan had a punishing schedule of feature milestones, that did not match either user need or technical feasibility. I kept some conformance with this by defering work on usability.
The end result seems to have been OK, and we now seem to have won the time to make up our usability debt. And I have had a good night's sleep, for the first time in some while.
Out of context
Edward, those points are interesting and may be very accurate in other contexts. But there are some details of my project which differ from your assumptions. My end users were in the same hotel the second day. My steering board are scientists of world stature. And we're not from either of the American continents.
An audit like this can also act as a useful reality check, to enable the project team to verify that what they are doing is what they think they are doing. To be useful in that way, it would have to be done in a slightly less adversarial fashion.
As you say, it was an inquisition. By my lights, an organisation that is putting up more than a million dollars is entitled to verify that it is being well spent.
Thanks for your thoughts, Chris...
...but American management style is independent of American origin, and it is used consistently in programmer management...with strikingly unproductive results in the form of late systems which fail the real users.
I sensed, based on my own worldwide experience, that it was as you confirm adversarial, and I question why this must be so.
For one thing, adversarial proceedings in law and business start with one side (in your case, the "users") thinking the worst of the other side, here, assuming that programmers are dorks more interested in technology than solving a problem: as if technology is not interesting because it solves problems.
The adversarial stance creates in the other side a form of bloody-mindedness in which justification supersedes doing a "good" job.
You quoted the user representatives, these world-class people, as saying "name one feature...". This is an implicit accusation that NO feature had anything to do with the users' problem, and that's a wild charge to which a person with self-respect would in my opinion would respond by leaving the room.
I agree that a million dollars is a lot of money, although given the horror stories of contract abuse coming out of Iraq, which I hope will be investigated by the new American Congress and from which I hope will result criminal charges, a million dollars, it appears, ain't what it used to be.
And I agree that oversight and audit is good.
However, if the user doesn't see, for example, the need for a fully normalized data base or adequate error checking, then a truly independent "audit" would investigate the user requirements as really meeting the abstract needs of the firm.
It sounds to me like a meeting in which the feminized and subordinated programmers "whined" that you can't do things a certain way "because" that would violate a good practice about which they've read inna book, while the monied end users, who don't read outside a narrow range, told the programmers that "they" don't give "a rat's ass", using, in the plush surroundings, the return of a repressed barbarism to show who's boss.
In my experience as a fly on the wall of Princeton, "scientists" of "world stature" often get that way by stealing credit, and dismissing graduate students as not worthy of a rat's ass, starting with the way in which Watson and Crick simultaneously discovered the double helix, and made damnably sure they, and only they (not their lab assistants) got the credit.
There are in my experience cases where the programmers have added features which make systems more auditable and more reliable, notably, in my experience, error checking.
But, in cases like yours, the ideological stance seems to be that "mere" programmers, as clerks, cannot do this.
"Millions of dollars" and "scientists of world stature" on the one hand, and computer programmers on the other, and minatory-to-abusive statements such as "name one..." which imply that the lower-down group has ignored the wisdom of scientists of world stature and wasted millions of dollars, do not create the preconditions for a dialogue, in which both sides treat each other with mutual respect and in so doing (as we have long known from the structured walkthrough) create a better system for all stakeholders.
Instead, a Platonic drama in which the superior term is closer to the pure Idea of necessity is created, and ALL instantiations of the pure Idea are found wanting along with their instantiators...whose funky dress in the fancy hotel constitutes the livery of servants.
The instantiators are of necessity befouled, no matter their education or experience, by showing the Platonists, as did Aristotle, that the pure Idea doesn't exist outside of some sort of realization with its own instantiated necessity.
The selection of an expensive venue was meant, as far as I can tell, to make the programmers, who don't stay at this kind of hotel when on vacation, that they are not independent professionals, but at best liveried servants or even slaves (as was Aristotle), whose intellectual product is meant to serve the ends of a self-selected subset of corporate players.
And, you had to take time off from meeting your deadlines to justify your worth in an "audit" that was not, again as far as I can tell, conducted according to audit principles by independent auditors...the independence of the auditing profession being a joke since the Chicago auditing firm Arthur Anderson fired auditors old-fashioned enough not to slavishly follow the money.
No, it wasn't an American venture. But it was conducted by way of Yank rules, in which a binary opposition is created between the people who do nothing but are insiders, and the people who do something, or, quite a lot of things, and then who are shown the door.
Now, a reversed polarity, in which the programmers dictate to the end users what sort of system they, the programmers, will build, is not what I am talking about here. That's what apparently obtained in the Soviet Union, but not in programming (where the programmers were subordinated to hardware types): instead, traditional civil and mechanical engineers dictated to the rest of the folk what they would build and on what schedule.
This, in other words, is Chernobyl. Neatski, right? Right.
This was a producer-driven economy and I don't think it's a good idea in programming.
However, I think the "world class scientists" in your case are not making any effort to meet the programmers half way.
At the same time the programmers I have known have almost to a man, never made the slightest effort (for example) to buy and read a high-quality daily newspaper such as the New York Times to inform themselves on what sort of issues concern high-level users, so there is fault on both sides.
Correction
Chris, I now realize that your review board did NOT say "name ONE feature that the user specifically requested", they said "name A feature..." which doesn't change the overall minatory tone but softens it.
I have to stand by my contention that these "reviews" are a waste of time whose primary purpose is employee subordination and discipline. They are a waste of time because you need employees with inner discipline and drive, and, you need to foster that by not working them to death!
But I apologise for unintentionally exaggerating the quote!
A friendlier criticism
My experience with Agile design has been fairly bleak as well. But I've always seen it torpedoed by a group of people, all of whom believe that they are doing the right thing for the company and the user community. Even when I know of personal animosities, I've always observed that people seemed to do their best to put these to the side to make sure the users came first. Perhaps I've just been lucky, but that's been my experience.
But good intentions don't necessarily translate to good results, and I think agile processes fail to reach their potential because they don't necessarily take into account human nature.
Perhaps I'm reading the wrong thing in to your account, but here's how I see it:
The dichotomy between the users who communicate well versus those who do not (and thus don't get the product to work as well as you would hope), suggests something rather different to me. When somebody tells me that a customer "does not communicate well", I wonder if it's really the customer who has the problem. I personally do not communicate well with people who tell me things I don't want to hear, and I don't suppose I'm the only one with that deficit.
How else can you explain the fact that this customer that you accuse of being incommunicative obviously has no particular problem interfacing with your governing board?
When a board member asks you *late* in a presentation to name a feature that was asked for by the customer, that makes me think that the first words out of your mouth at this event were not, "Here is a list of concerns our customers have brought to us. We've selected this subset of those problems to address. This subset was determined based upon projected revenue and from the estimated cost to implement all those things. Here's how we propose to implement them."
As developers and managers of developers, we're often much more excited about our solution than we are about the problem. I've seen this play out over, and over, and over again. I've also succumbed to this problem on solo projects without any help at all from others. As human beings, we're subject to a vision of the world that includes us as its center. Sometimes this serves us poorly.
But even allowing for our vanities in jumping to the solution before we talk about the problem, I'm struck that this governing board member who asked you "name a feature..." seems a bit lost. I mean, shouldn't he have known the answer? Shouldn't he have been aware of what customers were asking for in the next version of the product before he ever got to this meeting? Shouldn't he have been clever enough to see those parts of the design that answered some of those concerns?
Things we don't want to hear
"Here is a list of concerns our customers have brought to us. We've selected this subset of those problems to address. This subset was determined based upon projected revenue and from the estimated cost to implement all those things. Here's how we propose to implement them."
The problem here is that this language of agency can be short-circuited at any point by the structure of management language, because management has delegated the essence of management to technical specialists working for a wage.
One manager can in the Dallas playbook say, "how did you know who the customers are? You forgot about Billy Bob in Accounts Receivable, and I can tell you, old Billy Bob is hopping mad achoo".
Another can in London say, "you dogs, dare you to presume to select a subset? You were to implement all the requirements! Do you have an MBA, you low fellows? Tell me precisely what methodology you used to select the subset at once!"
You see, if one person or profession is defined as not worthy of recognition and respect, it's fair game at any time to accuse him or her of exceeding his mandate. The above hypothetical questions can be asked for the SAME reason "name a feature" could be asked, because Job One is maintaining, within the corporation, a virtual class hierarchy, and this job trumps profitability across the board (cf Harry Braverman, LABOR AND MONOPOLY CAPITAL: hey, if you have monopoly power, you no longer have to focus on growth).
I've asked it before and I'll ask it again: are we not men. The pernicious unintended effect of Weinberg was to render illegitimate that part of human nature which likes to find solutions and in so doing make the man in charge look like a damned fool, reminding the man in charge that history is made by all of us, not just him and his buddies.
Weinberg may have expected society to evolve in the direction it was evolving, in the USA, prior to the Iranian hostage crisis and the election of Reagan, key events which made today's world. This was one in which the greater humility of the 1970s programmer, guys like Wozniak, was in fact met until circa 1985 by greater respect on the part of management.


Sounds like an inquisition
...the purpose of which was to make sure the programmers knew who was in charge.
The programmers saw in excess of the user's needs features which may have been needed for the system to work at all, especially for the sort of employees and customers who don't get to attend bunfights in fancy hotels.
They were slapped down although the system is now the property of the company and will in no way be returned to the programmers, not for technical reasons, but for unstated social reasons.
American management was placed between capital ownership and the sort of people who questioned ownership as the REAL priesthood (the programmers never had a shot).
Because by definition there are no management skills (skills being by definition something that can be delegated in order to reduce management to pure agent will), management cannot establish its authority by deeper insight into systems. That insight is possessed only by people who work with systems, whether as technical people or as users.
Thus, management hypostatizes a User who as a convenient fiction can then be that sort of untouchable person who is forever and always offended by the very idea that a programmer might see something she does not.
Difficulty of system use is very convenient as an all purpose complaint. An older psychology wouldn't demand ease of use over and above correctness and would be willing to learn proper use of a software system.
However, American computer users are continually told that to use a computer they may be half awake, and, the failures that result are, in all cases, the fault of willful programmers who are vain of their knowledge and wish to show off.
Missing, somehow excised, is the very idea that one might be challenged or enthused by the very idea of using a new system without totally screwing up, because the screwups can always be blamed on the always inappropriate exercise of willful agency by community college graduates who know Visual Basic.
Or something.
Prevelant is a cold reluctance to admit that American society is anything more than a society of winners and losers, with the losers set to tasks so factored and monitored for efficiency that there's no point in taking that sort of pride in workmanship that might be late in delivering something that the winners want.
Sounds to me that there was no partnership, no human warmth, in that fancy hotel, only a struggle to establish one's bona-fides to be treated as an adult in the first place.
I've been there, and after 16 hour days and my wife's untreated depression, I am glad to have escaped. And I'm damned glad that the Democrats have won, because it will make the sort of people that stage the above bunfight all sad.