A few months ago, my friend and CODE Magazine contributor Ted Neward posted a statement on Twitter repeating something said by Billy Hollis: “Agile is treating the symptoms, not the disease”. This flame bait drew a number of responses that Ted later replied to on his blog (http://blogs.tedneward.com/)

From Ted's blog we learned the origins of Billy's statement. Billy was lamenting the complexities of the “stack” of tools we use when developing applications in .NET today. The number of technologies we use is staggering: SQL, MVC, EF, LINQ, WPF, WCF, MEF… and so on. I agree-whole heartedly that the stack of tools is complex and very difficult for developers to keep a handle on.

The blog post described how Microsoft and other companies moved from selling to “long tail” i.e., small development shops, into the “enterprise” space. This shift from small to large has left small shops in a difficult situation. Ted mentions in his blog post that not long ago, it was possible to build software with one or two developers. He asks “What chance do these developers have today?” Then he throws out the non sequitur (and I paraphrase at a distance here) “Agile development does not solve this problem.” And you know what? He is right. Agile does not solve this problem because agile has nothing to do with it. This statement in its radical context shift made me think of this statement:

“A woman needs a man like a fish needs a bicycle.”

This is a statement made by Irina Dunn and popularized by Gloria Steinem during the women's movement; basically, it means that women are not dependant on men. Just like women and men, agile development and toolsets are unrelated processes.

I am going to illustrate this point with the basic values of the Agile Manifesto (http://agilemanifesto.org/).

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Where do you see any mention of specific tools? In fact, the first line states individuals and interactions OVER processes and tools.

Agile is all about customer collaboration and building software not toolsets or specific techniques. If you drill down into the principles, you will see things like this:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These are just four of twelve principles. You will not see any details about specific tools or techniques. It is all about philosophy and how development teams interact with customers and each other and how they strive to build quality software. I will continue with some of my own questions to further illustrate my point:

  • Can I do Agile development using Access?
  • Can I do Agile development using FileMaker Pro?
  • Can I do Agile development using SharePoint?
  • Can I do Agile development using Visual FoxPro?
  • Can I do Agile development using an assembly language?

The answer to all of these questions is YES. You can do agile development in any tool you choose because it does not pre-suppose any specific tool or technique. Another very valid point that Billy makes is that there are a lot of agile zealots that say if you are not doing/using “insert nouveau idea here” you are not doing “it” right. Simply put, those zealots need to learn and implement a little pragmatism in their discussions of agile. Are some tools or techniques better suited to the agile style of development? Yes, there are better tools, but your definition of better may be radically different than mine.

In summary, agile does nothing to address the complexity of today's modern toolset. We will always be faced with an ever-growing list of tools and techniques we use. Agile is a process, plain and simple. In my next editorial, I will illustrate some ideas you can use to make your life simpler in tackling the “stack”.