his article was written in response to the opinion piece, “Are You Passing the Requirements Buck?”, by Lori Piquet, Editor-in-Chief of DevX.

Criticism Is Good, But
The agile community has no elected spokesman, and I’m not trying to elevate myself to this role (one would have to be insane to want to). I’m just a guy who’s in the position to be able to respond to Lori’s criticisms. DevX has a large number of readers, and it’s important that they’re not misled. Each of you will make up your own minds on the agile debate, but to do that you have to know what it is that our community is suggesting you do.

I believe that Lori’s article misrepresents agile practices in a number of ways, and in so doing may have damaged the ‘agile cause’?which is to improve software development practices to everyone’s benefit. The potential damage is that some people will believe that the community’s position is as she stated, and will turn away from what we believe is a very beneficial approach. Also, some critics of the agile approach, like Matt Stephens, author of Extreme Programming Refactored, are happy to use statements such as Lori’s as if they’re authoritative without investigating the underlying truths, or actually trying things for themselves.

Criticism is a great way for us to learn about what we’re doing wrong and what we’re saying badly, and we use it to develop and improve. So, criticism is a good thing. However, Lori’s article wasn’t critical of the agile community, or of our suggested practices, it just seemed to be. Nobody in the agile community has ever suggested the practices she is criticizing. In fact, it’s hard to see how her article is a criticism at all; generally it is in line with ‘agile’ thinking.

Lori seems to be suggesting that agile developers are shirking their responsibility; she believes that we want the business to take all the responsibility, do all the work, and come up with all the requirements without our input. Not only have we never said that, but as the rest of her article shows, it’s insane to think that’s even possible.

Lori says that she disagrees with the basic premise of Scott Ambler’s work. She says that, “The process of creating software requirements simply cannot be decoupled from the technical knowledge base, and that technical knowledge base lies in the brains of developers.” She’s right, of course; requirements are born of a mating between technical and business knowledge. Where she’s mistaken is in the assumption that this is the basic premise of Ambler’s work, and by her extension of this as a basic premise of the agile community.

It seems that this isn’t entirely Lori’s mistake. Ambler is a prominent member of the agile community, and one of its most prolific contributors. Despite this, some members of the community believe that his presentation of some agile principles is open to misinterpretation. However, it is probably impossible to write a message that everyone will understand unambiguously.

And, although Ambler enjoys a senior position in the community, it is a mistake to assume that his views and the community’s are synonymous. We are as diverse in our approaches to software development as any other group of developers. What joins us is a common belief that classical development methods are doing business a disservice and that we can and should do better, and that while technology is important, process is more important, and that while process is important, people are more important still.

Roles and Responsibilities
Lori’s article isn’t all bad. Its mainline reasoning is that requirements should be created by consensus, not by mandate; this is right, and in line with the work of the majority of the agile community.

Developers have a special role on a development project. Ambler’s work tries to separate that role from others as a way of talking about this special nature, not as a way of separating developers from their responsibilities. Some people disagree with this approach, most notably Ron Jeffries, who wrote, “This is a very weak distinction upon which to be excluding [developers]. If you made statements like this during your talk, I can see how Lori would have been confused.”

I’m sure that if you were to put Jeffries and Ambler together their actual approaches wouldn’t vary much. What we’re witnessing here is a discussion about presentation, rather than approach. Ambler singles out developers for special treatment, Jeffries thinks that this conveys the wrong message. Given Lori’s misunderstanding, it seems that in at least one case he is right.

Lori writes about, “Ambler’s belief that requirements are the sole domain of business managers, or ‘stakeholders,'” She seems to believe that he is suggesting that the word stakeholder is synonymous with ‘business managers’. However, his work states clearly that stakeholders include, “direct user, indirect user, manager of users, senior manager, operations staff member, support (help desk) staff member, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.” There are a lot of non-business people in this list.

Ambler explicitly leaves developers out of his list so as to give them special attention elsewhere; they play a different role, and have different rights and responsibilities. This doesn’t mean that developers aren’t also stakeholders, just that if one classifies them as stakeholders they get treated as stakeholders. That developers are different is clear, and that they should not be treated as ordinary stakeholders is also clear. In OO terms we might model developer as a specialisation of stakeholder; a subclass.

Lori also wrote about the apportioning of responsibility with respect to requirements. She believes that Ambler apportions this responsibility solely to the business-side stakeholders. I believe that here we have a misunderstanding about the word responsibility. Jeffries has this to say, “I fully agree?FULLY?that when it comes to requirements, the customer has the last word. I would put it that way: the LAST word. Before that last word is spoken, the customer needs to fully understand the programmer, and the programmer needs to fully understand the customer. It’s not a one-way transmission; it is full on, wide band, hot communication.”

I think that Jeffries is too insistent on ‘full’ understanding, as good software is often forthcoming with somewhat less than this; it is enough that developers and business people understand each other enough to make correct decisions. It is also likely that ‘full’ understanding can only come when we’ve more fully developed our telepathic abilities.

Ultimately though, someone has to be responsible for the choice of features that are being developed. I don’t think that anyone would suggest that this responsibility should fall to developers; we specialize in software development, not business decisions. This responsibility has to fall to someone trained and experienced in making spending decisions: Stakeholders. Developers may advise them?they may even allow these groups of stakeholders to vote on appropriate features?but eventually the responsibility usually falls to one person.