Apologetic Agile Development
Having lived through numerous attempts to build software embracing the concepts behind the agile manifesto, I feel there are three large categories folks fall into when talking about agile principles.
- The curmudgen - these folks have been writing code since punchcards
where the state of the art, OR they have been brainwashed by large
consulting organizations into thinking that a large heavyweight process
is the only way to succeed. Note, a subset of these folks believe that
"no process" is actually OK and are quite happy to cowboy-code their way
- The fanboy - these folks think "everything agile all the time" and
will rename status meetings to "scrums". These are folks who are used
to working solo on projects that they can do in their heads... or they
are simply not clued into the implications of actually having a
repeatable process or delivering working software.
- The apologetic - these folks understand the principles and the value they provide, but also understand that these principles are the important thing and know that the current state of the art of software development is still very problematic. These folks often complain or quip that they are not doing "real agile", but accept that using some of the tool and principles coupled with more traditional principles, tools, and processes has much more value in most cases
I'm squarely in the apologetic camp (my ego transposes apologetic for pragmatic BTW), and while I feel I have a good understanding of where and how agile can deliver value, I also understand that many times agile gets sold as a magic bullet that never delivers completely on it's promises. I think this is a mistake: No process, methodology, or tool is perfect, folks who complain that "agile" causes problems in their projects or doesn't solve problems that they have are completely missing the point. No process, principle, or methodology should completely dominate your software development philosophy and enlightened developers should stop apologizing.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)