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:
- They "do not take a systems or engineering view of development".
- Customers are "the only stakeholders identified in system
development models like agile methods...".
- "... they quite specifically narrow our focus in dangerous ways."
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.
-----