Recently, a client of ours sent me this article on Agile development by David Longstreet (PDF), and asked me what I thought of it.

Here are my thoughts:
1. This article is highly entertaining! At first, the graphics put me off, but then I read on.
2. Longstreet is accurate on many fronts and levels, has deep insight into organizations (worldwide), and is articulate in illustrating how Agile is lacking.
3. Longstreet pinpoints the issue with Agile development: it is not going Agile that will solve all of our business, development, and project issues, but those problems need to be addressed at the source - most pointedly at the fact that requirements gathering is currently in a state of shambles, but is not addressed by Agile development. In fact, Agile tries to ignore the need for requirements gathering altogether.

After reading the article, my own conclusion is that Agile only works under very specific and rare conditions (Longstreet does not even make this concession). Basically, the project team must:
1. Have clear and established requirements for their end product(s)
2. Have abundant and deep skills in Tech/Dev, UX, and Business (and can play together nicely)
3. Have a homogeneous level of skills
4. Have a homogeneous work culture, and an established or well-defined workplace structure
5. Work at break-neck speeds, and maintain that over time (not burn out)
6. Know their customers extremely well
7. Be highly creative (each in their fields)
And here is the clincher: The team must:
8. Have tried the Waterfall Method, has mastered that, and want something faster

In all of my own experience with over 150 projects in Canada, the U.S., and worldwide, there may be only one or two organizations that qualify. One is a specialized division within a large Canadian bank and the other is a privately-held company in the U.S. Even then, Agile may only work for them in a limited way. None of the government organizations that I have ever worked with would qualify.

To further prove how difficult it is to fulfill the above conditions, think about how certain characteristics above do not jive with others. For example, an organization that has abundant and deep skills on all fronts is usually a more mature company or organization. On the other hand, an organization that can work at break-neck speeds, have a homogeneous work culture, and is highly creative - may lack the business and process maturity required to pull off Agile. Furthermore, the younger companies usually have not mastered the Waterfall Method.

Longstreet has guts that I will never develop. I must admit: as a UX practitioner and consultant, I have made concessions - thinking that if we cannot win over organizations and their adoption of Agile, then let us join them. I thought: We should have an Iteration 0 that would mitigate some of the shortcomings of Agile dev, and do our best in spite of Agile. We should do things like Discovery UX Research, Alignment Workshops, Design the Box, Back Casting, Project Goal Setting, etc. All this is great and needed in our projects - but is Agile methodology really just a poor excuse for lack of processes, methods, direction, and strategy? In many cases, Agile might just compound the ill effects of a directionless or dysfunctional project or team.

Posted in Opinions on March 9, 2008

blog comments powered by Disqus