I found a really good podcast called The Agile Toolkit Podcast, in which the host, Bob Payne, attends agile conferences and interviews people there. Some of the interviews include people like Bob Martin and Mary Poppendieck among many others.

The most interesting show I’ve listened to so far is an interview with Dave Thomas (of Pragmatic Programmer fame) about agile development.

For me, I think I found it interesting just in the fact that it is nice to hear someone that has the same views on development issues as I do. I’ve always been a big believer that methodologies are limiting and that each methodology should be tailored to the project team. One part of the conversation that I found extremely interesting was when Bob and Dave were talking about the dogma attached to many of the methodologies.

Recently I had attended an Agile Development training in which the instructor stated that if you weren’t using all of the components of XP, you weren’t doing Agile development. A good point that Dave made was that as XP was being developed, the teams it was being developed with actually evolved into using all of the practices at different stages of their team development. In other words, they didn’t start using all of the practices specified in XP – because they didn’t exist yet. Dave makes the point that teams need to evolve into all of the practices – and that its very difficult to implement all of them at one time. I actually think that each team will be sufficiently different enough that you may not need all of the practices, but only a core set of practices. Bob Martin also makes this point in his interview and lists the minimum set of practices that include very short cycles, an open office (a room which holds the identity of the project), test driven development (both unit and acceptance tests). He also mentions that its extremely difficult to do test driven development without continuous integration, so there are other practices that will be necessary as you begin to implement the minimum set. I actually believe that source control and automated builds are another of the core minimum practices that should be put in place before anything else – but thats just me.

Another area that Bob and Dave talk about extensively is the necessity of developers to look at other languages in the industry other than the core language they use day to day. One statement Dave makes is that he looks forward to the day that developers refer to themselves as “developers” rather than “Java developers”. I wholeheartedly look forward to that day as well.

I’ve always enjoyed learning new languages. If you run through the articles in this blog, you’ll see that every time I find some language that I don’t know – and understand the practical reasons why they exist, the chances are I start working in it right away (most recently, this language is Objective-C). I enjoyed this part of the conversation a lot, because Dave articulates very well how learning new languages can give you new insights as to how to implement things in different ways.

I’m a firm believer that in software development, you have to have a pretty large tool box. The right tool should be used for the right job. This is why in many of the things I’ve done over the years, different components are written in different languages depending on what I am doing. A web piece might be written in PHP, scripts done in PERL or Python, while other components could be written in C / C++. I’ve made a conscious effort over the years to expose myself to as many different languages as possible.

In order to have the flexibility to use the right tool for the right job, you really have to make an effort to get at least a high level understanding of the different tools available and what their strengths are. Thats the really nice thing about the conversation with Dave is that he articulates the idea that you don’t necessarily have to be an expert in all languages, but know enough to use them and glean knowledge from them and their design.

I have found each of the shows I’ve listened to from the Agile Toolkit Podcast very informative and totally worth the time investment. In the very least, I want my teams to make this a part of their learning program moving forward. There’s no better place to learn about Agile practices than from the people right in the middle of it.