I’ve been asked a few times recently what I feel the best projects for “agile” methods are.
As I mentioned in a previous posting, I view “agile”/”rup” etc as more tactical versus more strategic methods of attaining goals.
Therefore I obviously believe that projects that are more “researchy” or “startupy” make more sense as far as taking a more tactical approach.
Eg, if you don’t know what the UI is going to look like, what features the customer wants, etc, then doing little to no design up front makes sense, and small iterations are handy for generating consensus and a road map of what to do next.
However, projects that have a concrete spec, where the goals are well defined, and the interfaces are well defined would tend to benefit from a more traditional, and less chaotic approach.
I believe all projects can benefit from an incremental and iterative development process; however the increments would tend to be small for the more “agile”/tactical projects and larger for the more traditional projects.
Note: I use “agile” with a small “a” not a large “A”; that is because I believe agile is a tactical mindset, and the tactical approaches to be used are up to the user. I do not believe in the “dogmatic” forms of agile, such as XP, nor do I consider some of the XP edicts as beneficial on any project (Pair Programming all the time, Refactor Mercilessly, Collective Code Ownership across tiers, etc are never on my radar).
I still believe in specialists and enough upfront design to avoid “merciless” refactoring; (I’d rather have merciless design and prototyping so that the production code doesn’t need to be mercilessly refactored).
I believe in concentration too so of course I’m not a big fan of pairs or noisy team rooms.
I’m happy to work shoulder to shoulder as the need arises, but I don’t confuse that as a substitute for lack of documentation by having people work shoulder to shoulder constantly in an effort to avoid having appropriate documents.
However much some methodologies claim to “lower the cost of change”, change is still lower cost to achieve at the paper/design level before it is turned into code. Therefore I like to leverage that cost savings as appropriate (eg, more design, less refactoring).
My approach is to combine what’s good and appropriate about all the methodologies and combine them in a way that makes sense for the project at hand.
Jordan
