TITLE: Agile Fading? AUTHOR: Eugene Wallingford DATE: December 05, 2008 4:59 PM DESC: ----- BODY: An acquaintance of mine sent a link to James Shore's The Decline and Fall of Agile to a mailing list with a warning: "You probably don't want to read it if you're a follower of the religion." His use of the pejorative reveals that he's not a fan. He is a strong believer in design -- if not BDUF, at least more than he perceives agile methods to encourage. I read Shore's articles anyway, so I was happy to now. I don't think of myself as religious on this matter, but I often speak positively about agile approaches (I might say "fairly") when a colleague expresses what I think os a misconception, so here goes... Shore is right. He also echoes something that comes up every so often when I am discussing agile approaches with folks who have had a bad experience: When a company does something it calls "agile" but which is unsound (perhaps because they leave something important out), things usually do not go well. But that's because they've done something unsound, not because they call what they did "agile". I really try not to be a knee-jerk apologist for agile methods. They don't solve every problem in the world; nothing does. So when someone tells me that agile has failed them, I try to listen carefully to what they've been doing. Otherwise, it's too easy to say, "Oh, you did it wrong." That's the sort of behavior that leads people to talk about religion. And it's intellectually sloppy, which bothers me more. But sometimes people do have a misconception, or do leave out an essential practice, or do something else that counters the desired benefit. When someone tells me,
[Extreme Programming] says you should spend no more than 10 minutes on design during a three-week sprint. 10 minutes!
... I have to say something. Maybe some agile evangelists have said this; maybe not. But it's wrong, and someone has to say so. For what it's worth, my understanding of XP goes back to the original spirit: If doing something is valuable, then why not do it all the time? As a result, I encourage the teams I work with at the university and in industry to think about design all the time. But I also encourage them not to design too far ahead of their code base, because that is too often untested thought. Refactoring, a practice that some design-oriented people like to deride as "not doing it right the first time", is a key part of the design process. (Teams that don't refactor all the time are usually in big trouble -- and then unhappy with the other agile practices they have adopted.) As with any idea that becomes more buzzword than idea, there is always a huge risk that the energy of the "movement" will flame out early when things don't go as predicted by eager creators and early adopters. We see the same thing happen in educational settings all the time. Many of you have lived through objects-first in the CS curriculum. Software patterns encountered the same fate. Hype outran practice. When this happens, it is usually best to let the fad die out. The good news is that some people will persevere with the good part of the idea and do wonderful things. The most recent patterns example I know of is the resurgence of interest in patterns in the parallel programming community, which faces many of the same challenges that faced a world moving to object-oriented programming faced fifteen years ago. The Parallel Computing Laboratory at Cal-Berkeley is undertaking an ambitious pattern language project in this area. Echoing Shore:
What frustrates me the most is that this situation is entirely avoidable. In a green-field environment, the solid agile engineering practices included in Extreme Programming pay for themselves within the first few months.
When this passage leads the person with whom you are speaking to say,
I didn't know anyone used XP anymore. I feel sorry for them.
... you'll know it's time to stop talking. The religion that is getting in the way of developing software better may not be on the agile side of the conversation. -----