Names Are Important

This article on the resulting change in a development shop after they adopted Agile popped up on Reddit today and the comments there got me to thinking again about the ramifications of changing the meaning of a term or phrase while still using the term or phrase to describe it.

Last week, we had an internal conversation regarding this Ron Jeffries’ post where he talks about the essence of Agile Software Development as he and others defined in the Agile Manifesto. Leaving aside the idea that the Agile Manifesto is a set of values and not dictates, one of my colleagues made a good point regarding how it was too late to discuss what Agile meant because the term Agile had been bastardized in so many ways as to be irrelevant, poetically paraphrased. A comment on the Reddit thread above made the same point, that in our industry, once you put a name on something, you have essentially relegated it to the dustbin of history because once something has a name, people can latch onto the name while changing the underlying structure of what the name stands for. Many people say that the beauty in agile is its flexibility but when something is so flexible as to have completely different meanings depending on how it is implemented, naming it loses all meaning.

The term agile should be be viewed as a descriptor of a philosophy of programming and not as a concrete implementation of how you develop software. Even Agile Software Development is philosophical in nature and aside from the main tenet of delivering usable, valuable software regularly, it is a term that should be used to light but not build your path. If your team writes a detailed specification at the beginning of a project and then iterates over that specification regularly delivering working, usable software, you are using agile philosophy even if very few agile coaches would teach that way. Having a philosophy guides your decisions but does not dictate your decisions. The failure to not clearly state this is one of the larger failings of the agile community.

Of course, by plastering a name onto something, you practically guarantee that someone will try to make money off of it, especially if it becomes a part of the software culture. However, it would be hard to make money being an agile coach if your coaching totally consisted of Yoda-like platitudes. “Deliver working software sprint 1 you will.” So the term agile became a description of directives and that’s when it started to significantly lose meaning. Saying you do agile software development now means you’re doing something that superficially looks like Scrum or Lean or XP but is so drastically different under the covers that the term “agile software development” has no meaning.

The best agile coaches understand this. They look at a process in a development cycle and try to decide if it fits into the philosophy of agile as opposed to the particular pragmatic implementation of agile that the team is working under. If it does, the process can be kept. If it does not, the process needs to be revamped or eliminated in favor of one that helps the team deliver software. Anything else violates the philosophy of agile software development.