Diving into the World of Agile Methods

I think it's time for me to abandon the general small talk and get to some serious business. So, from now on, I'll try to stick to more software-related things.

Today I attended a lecture on software processes by Professor Inkeri Verkamo. The highlight of the lecture was a short comparison between agile and traditional processes. The view on agile process was based on Alistair Cockburn's Learning from Agile Development (CrossTalk, Oct & Nov 2002). Although my knowledge of agile methods is very, very limited, this short introduction offered little I didn't already know.

However, one of the important features was the presence of slight criticism of agile methods. (I'm eager to see Markus considering the alleged pros and cons of agile methods he heard at JAOO 2005.) Cockburn's views were considered to be quite objective, but some of their shortcomings were also mentioned. It is usually said that agile methods are more flexible than the traditional ones and can adjust well to processes of different size. However, most of the examples that are often given involve a programming team of 2-4 people. It's not obvious if the same methods apply to a group of 30-40 developers as well. It's also often said that agile processes don't tie developers' hands but let them use their skills better than the traditional processes. This is probably true, but it also implies that agile methods - using Verkamo's words - "rely heavily on the excellence of the developers". I know from my own experience that a novice programmer is more a burden than an asset when teamed up with experienced "gurus". Pair programming might in theory solve this problem, but sometimes the skill gap between the developers can just be too big.

Agile processes may very well address these things and I sincerely hope I find it to do so. Still, a good student should always challenge the things she is told. The Agile Manifesto should not be seen as the new Holy Bible, but be taken with criticism. No matter what option a software developer chooses, she should always be able to justify the choice to herself and others - and "The others told me so" is never a valid justification.