I came across an interesting article written for Visual Studio Magazine about agile methodologies where the author makes what I consider to be some misconceptions.

The first is around the level of experience of people working on an agile team:

I wouldn’t say I have a high level of experience and I’ve been working on agile teams for the past two years, just one data point suggesting that this statement is not actually accurate.

I think it is important to have experienced team members, at the Journeyman or Master level to use the lingo of Software Craftsmanship, but I don’t think you’d want your team to be completely filled with these types of people.

This is one of the things that is pointed out in Pragmatic Learning and Thinking referring to the Dreyfus Model definition of expert in this case. We need to have people of differing levels of experience if we are to create a successful team.

This is referring to the fact that as people become more competent they tend to start focussing more on the big picture than they did when they just started learning. As the authors point out, it’s useful to have some people on the team who just want to focus on the details and get things done.

Of course I’m sure there are examples of 'dream teams' of software developers who have worked successfully together, but maybe this is more the exception than the rule.

The second point the author raises whether agile is just about making developers comfortable by allowing them to write more code:

It is fair to say that when working in an agile way we get to the code more quickly than when following some other approaches but surely that’s a good thing?

Although certainly some part of design is best done at the whiteboard, we can’t actually know whether our designs are going to work unless we put them in the code so I don’t see design by TDD being a problem.

There is a need to do some requirements gathering before we start working on features/stories but quite often we don’t find out about constraints and trade offs until we begin implementing a feature, at which time the customer can decide what approach they want us to take. The goal here is to try and provide them quick feedback so that what we develop is actually what they want.

I would encourage the author to go and see an agile team at work (maybe using the Patterns and Practices team at Microsoft as an example) and see whether he believes this points still hold true.