TITLE: Professionalism and Agile Methods AUTHOR: Eugene Wallingford DATE: July 23, 2004 10:00 AM DESC: misconceptions about agility and concern for others ----- BODY: Don Gotterbarn, writes the "Thinking Professionally" column in the SIGCSE Bulletin. His most recent column (Volume 36, Number 2, June 2004) suggests that agile development methods are unprofessional. Here are some of his assertions: He includes RUP in those admonitions, but he reserves some of his harsher words for agile methods. He speaks dismissively of "designing a web page while agilely chatting with the customer". Later, he says, "Agile methods' emphasis on a 'people-centric view of software development' is about supporting the individual developer's needs to feel free to be creative and not about a concern for people affected by the system." These words sound rather disparaging, but I think they reflect a common misconception of agile methods by some in the software engineering community. Such folks often see the agile methods' emphasis on different elements of the development process as a rebuke of their own professional concerns. The result is often an overreaction to the agile methods. (Some of the hype that ushered in XP probably didn't help this situation, either.) In particular, I think Gotterbarn's article reflects two misconceptions. First, it assumes that agile methods do pay not adequate attention to gathering requirements. While some in the agile community have written a bit loosely of unit tests almost as a replacement for requirements, that's not what the agile methods actually call for. (Brian Marick makes the distinction quite nicely.) For example, XP's "planning game" prioritizes and selects from product requirements that were developed in consultation with the client. The key point XP makes about requirements is that the client should be responsible for business decisions, and the developers should be responsible for technical decisions. Second, the article assumes that developers using agile methods are not allowed to use their professional judgment. I don't think that any proponent of the agile methods thinks that or wants practitioners to behave this way. A professional can explore the context of a project with the client. A professional can use his or her domain knowledge when choosing stories to implement and when implementing them. A professional can acknowledge a lack of knowledge about a task. For example, several of Gotterbarn's examples are based in poor user interface design. Designing a user interface without knowledge of the intended user audience is unprofessional regardless of the development method used. Likewise for designing a user interface without knowledge of usability design. Perhaps both of these misconceptions ultimately come back to the agile methods' emphasis on the separation of responsibilities between the client and the developer. Certainly, agile methods depend in large part on the client specifying an appropriate system, in collaboration with the developer. That won't be different under any other software development method. Gathering requirements is still essential to building good software, and it is still difficult to do well. One of the things I like about the agile methods is their emphasis on communication, on close interaction with the client, precisely because they give the developer an opportunity to be a more active part of the conversation that defines the project. Agile methods don't tell us to turn our professional judgment off, or to ignore what we know about the domains in which we work. They do encourage us not to substitute our expertise for the client's in relation to the client's domain and needs. They do encourage us not to run too far head of the client's needs, not to build a system that is bigger, more complex, more costly, and more error-prone than the client needs. I don't think that any software professional or educator can disagree with these goals. -----