This is one of the more annoying questions I get. Nothing against the people that ask this question. It’s a perfectly reasonable question for someone to ask. However, for me, the implication of this question can be off putting. It’s as if some people think there’s an Agile committee waiting to sign off on whether a project is “Agile” or not. Who knows, maybe there is at their company?? <tangent>Reminds me of the CMMI. Nothing against CMMI — that is, if you like paying lots of money for someone to tell you nothing about whether you can deliver functioning software.</tangent>

On with the story…

Recently, someone asked me: “If we’re not doing TDD, is our project ‘Agile’?” First, why is it relevant if someone else considers your project to be Agile or not? Second, and how I answered this particular “developer testing” question was that it depends upon whether you want to learn about a defect as soon as it’s introduced when combined with a Continuous Integration system. Or…whether you want to learn quickly that a new feature caused a previously implemented component to break. To me, that’s more relevant. Not whether you’re “Agile” or not - in this context. In my experience, this question is often not about whether it’s in the “box” called Agile (a fine question, by my standards), but, instead, whether someone else would “label” me/my project as Agile or not. To me, this is an important subtlety as it makes me think they’re looking at it like it’s a checkbox rather than a way to improve software development. So, I guess I’d feel better if they’d ask me “Paul, what is the value of the test-driven development practice in the context of the Agile methodology?” or “Name some problems when using TDD”. Now, we’re getting somewhere.

I appreciate, use and advocate many, but not all, of the “Agile” practices because they make sense to me and the teams I’ve worked with. Personally, I probably lean more toward the “collection of best practices” approach (used in context) than pure methodologist. Furthermore, I’ve adapted (agile, no?) these practices based on the team environment and skill sets. For example, I’ve started teams out with a daily build because I felt that Continuous Integration was going to be too much for this particular team — at first. After a few weeks, we moved to Continuous Integration with compilation and unit tests. Later we added inspections and deployment and so on.

Let me beat my point into the ground…For instance, I believe that running a scheduled build that occurs once an hour is not “Continuous Integration”. However, how much does it really matter if it’s called “Continuous Integration” (I consider this to be “Scheduled Integration”)? I mean, will the authors of Continuous Integration use you as an example in the 2nd edition of the book? Let’s, instead, discuss the pluses and minuses of this approach. A minus, to me, is that a build runs regardless of whether you committed a change to your version control repository (seems like waste to me). Another minus is that it could distract you from something you are working on if it fails. However, there are a lot of pluses to it. For instance, as long as you’re keeping up with it , you’re ensuring your software is building successfully on a periodic basis and you’re learning about this more often than alternatives (such as 1) never 2) weekly 3) daily, etc.)

Don’t miss my point, labels do matter. In fact, my company helps teams optimize Agile software production . I appreciate and believe in the value of wrapping a word/label around something (e.g. “Agile”, “SCRUM”, “Unctuous” and so on) Further, it can help you determine what a practice/methodology is and what it is not. But, utilize the practice because it makes sense not because some “thought leader” told you that you better do this or I won’t consider you “Agile” (Look into my eyes…now at the swinging watch…you muuuust listen to me on this one ). Also, I think some are hesitant to say “well, it depends” because they may be afraid that people won’t follow their advice. Oh, if “they” could only see it my way…