What's good and bad in agile methodology?

Frank Kelly has some good Thoughts on Agile Methods - XP and the like.. He's a skeptic of dynamic languages, and of course I'm an avid user of and advocate for these, so I was almost put off by his first couple of paragraphs, but I think in the end he nails the essential points.

Whether you create a design or not - the second you write a line of code you are realizing a design - it may be in your head but it's still a design. If you are on a team of more than about 7-8 developers then to really "scale" communication a written and agreed upon design is a very helpful (I would say 'necessary') task on the path to to success.

but, as he admits:

As I've said before Agile has taught me that at many times "less is more" - so I tend to write smaller design documents with lots more pictures and try to always keep them under 20-30 pages or so. From there on, 1-on-1 and team meetings can help get the details out. Also you can farm out individual component designs to individual developers - each creating a small 5-10 page document. Beyond that you do get the "glaze over" effect in people's eyes.

This is exactly right, and it has been my attitude to agile methodology. You can't ignore design, but you can make it less of a white elephant. As I wrote in "What is this ‘agility’?"

It’s not easy to come to criticism of BDUF. After all, it brings to the young profession of software engineering the rigor and discipline that have established other engineering disciplines so respectably. No one would commission a skyscraper or build a jet plane without mountains of specifications, models, surveys and procedural rules. It would seem that similar care is the only solution for the bad reputation software has earned for poor quality.

Despite this, there has been a steady movement lately toward “agile” techniques, which contradict BDUF. Agile boosters claim that BDUF is impractical for all but the largest and most mission-critical systems, and causes a lot of problems because inevitable change in requirements and environment are very difficult to accommodate in the process. The track is laid out during analysis and design, and any variation therefrom is a catastrophic derailment. Agile methods focus on flexibility and accommodation of change, including greater involvement of the end user throughout the process.

One area where I tended to disagree with Frank is in his discussion of the "waterfalls" approach to the software development life cycle (SDLC):

Here's my issue with rejecting waterfall - it's like rejecting Gravity - that's all well and good if you live in a parallel universe where the laws of physics don't apply :-)

He goes on to imply that you are rejecting integration testing and design when you reject waterfalls. I strongly disagree. Let's say there are strong and weak agile methodology supporters, and that Frank and I are examples of the weak sort based on our attitude towards design, (with our belief that some design is always necessary). I think the part of waterfalls that most weak agile supporters reject is the part that gives its name, i.e. irreversible flow between stages of the SDLC. The problem with waterfalls is that it is the contrary to iteration, and I think iterative development is important. I think Frank does as well, given his acceptance of more, smaller releases, so I think our difference is less substantive and more a different understanding of what it is in waterfalls that agile methodology rejects.

[Uche Ogbuji]

via Copia