TITLE: Isaac Newton, Failed Agile Software Developer AUTHOR: Eugene Wallingford DATE: October 14, 2004 8:15 AM DESC: Another professional article criticizes agile methods in a strange, unsatisfying way. ----- BODY: Every once in a while I run across an article in a journal or trade magazine that reflects some misunderstandings about agile methods. Last July, I blogged about an article from a CS education magazine which asserted that using agile methods was unprofessional. (Presumably, then, so is teaching them as a viable alternative to traditional methods.) Yesterday, Steve Berczuk pointed the members of the XP discussion list to an article in the October issue of IEEE Computer called "Do Agile Methods Marginalize Problem Solvers?", by Victor Skowronski. (The article is available on-line to IEEE-CS members.) As Steve said, this column "sounds like it was written by someone who has read about agile methods but not used them." Skowronski's argument seems to be this:

Excellent problem solvers often have personalities ill-suited for teamwork and, further, must often work in ways that do not match well with teamwork.
Agile methodologies favor people with lesser technical skills and strong "people skills" over excellent problem solvers and others with technical skills whose people skills are subpar.
Thus, agile methodologies are unsuitable for environments that require excellent problem solving skills and thus must attract people who have them.

This, of course, means that agile methodologies are unsuitable for many (most?) software projects. The article uses two of history's great thinkers as examples: Isaac Newton and St. Thomas Aquinas. Apparently, Newton wasn't much of a team player, feuding with rivals, guarding his advances until publication, and preferring to work in isolation. Aquinas, though, was just quiet, a man living the life of the mind irrespective of his social circumstances. Would I really want a Newton on my team? Most software developers aren't writing software that will change the intellectual foundation of a discipline or even a company. They don't need to create new ideas of the depth and complexity of Newton's advances. Most software developers also don't get jobs for being pains in the behind. Would I want Aquinas on my team? Maybe. I can imagine having an excellent programmer be a valuable contributor to my team even though he is unable to pair effectively. I've never worked in such an environment, as my agile background is limited to teams that chose to use agile methods on their own, but I can imagine it. Maybe over time the loner becomes an effective pair; maybe instead the team adapts to the loner. It could work. Like so many articles of this sort, this one projects a lot of details into the description of agile methods that aren't really there. Perhaps this projection follows from never having tried agile methods, or maybe from an ideological bias. In any case, this article makes assumptions that demean agile proponents' professionalism and ethics. Forcing programmers into a communal workspace with no opportunity for either personal or professional privacy in the work place? Discouraging the writing of all documentation? Building software without adequate knowledge of one's task, tools, and domain? Please. Those aren't agile practices. They are just bad ones. A big part of the article discusses how the phases of problem solving fit with an agile approach, but it is largely beside the point. When an agile team needs to solve a thorny problem, agile developers can read books and seek other sources of information. They can take time away from the active production of code, if that's what's needed. The team can make reasonable decisions about how to advance its work. I did have some good thoughts as I read this piece, reminders to be agile:

Adapt to your personnel. Certainly. Agile processes aren't just about software; they also encourage us to be agile in how they work with people.
That said, you should take care in assembling any software team, and an agile team is no exception. You may choose not to have a Newton or Aquinas on your team, if they don't fit. You might choose not to have lots of different kinds of people on my team.
Don't overlook developers who can contribute value but don't fit your stereotypes. This is a variant of the previous point. The article reminds us that a good problem solver who lacks people skills may seem less competent than a person who fits the agile mold. We certainly don't want to overlook potential contributors. We need to watch for opportunities to bring potential contributors onto the team and help them to contribute. They might even grow in the process, too.
Use methods appropriate to your project and environment. Well, certainly. Agile is as agile does. We need to mold our approach to the task at hand. But that doesn't mean throwing out things that we value as essential, like communication.

Throughout this article, the author seems to imply that you can't find good problem solvers who are capable of working on an agile project. Hogwash. Not every person who excels at problem solving behaves as badly as Newton. I know a lot of smart people with great technical and problem-solving skills who use agile methods and like them. They wouldn't choose to develop software any other way. Furthermore, not all software teams need a problem solver as singular as Newton. Writing software is hard, but it is rarely as hard as inventing the calculus. One other claim caught my eye. This article defines the "best programmer" as the one with the most advanced problem solving skills. This is almost certainly the wrong answer. The best programmers are those people able to deliver high value to their customers for suitable cost. Problem solving is certainly an important component in being able to do that. It is essential that software developers be able to think deeply and to find solutions to thorny problems. But problem solving is not the only requirement for a good programmer; indeed, often it's not even the most important one. I know that this article is presented as an opinion piece, in a column that the editors of IEEE Computer hope will stir up foment. In that regard, I suppose, this piece succeeds. But still I wonder about the disinformation and misunderstanding of agile methods that cause people to write such stuff. I hope that Mr. Skowronski does better research before diving into one of those really hard problems that he needs to solve. -----