The developers, though they are bright and easily can learn and adopt these all good practices, are never gone into this practice at all. For example if the developer grown in an organization where the co-developers and seniors are not enough talented or open to teach the juniors, the best practices. They always use them as an assistant to complete the/his work and never spend time or coach them. Even these senior developers are also grown and came to this organization like this only.

Gradually, the juniors with these all bad practices will become seniors and the story continues…

So what I feel is it the responsibility of the team leads, senior developers (all doing all these practices) should also spend time to educate and coach juniors.

I more believe that the situation is like with a friend of mine who works at a big company and who just doesn’t believe that “standard” developers can use such a “geeky” technique. Most people don’t see that agile isn’t any “harder” than standard development. They just hear all those fancy terms and think is complicated or esotherique or something like that – maybe they also think “it works our way and we did it this way forever – why change?”.

A company with 50 crap developers can work agile. Just invest some few days and teach them. And maybe this helps them getting away from what may just be “crappy” organisational structures and too much bureaucracy.

First, everyone is someone else’s crappy developer and it is very difficult to separate the good on the right and the crappy on the left. Second, often you have to make do with what you have and trying to identify who is at fault just wastes time. Often, I think if I am only working with good developers, either the crappy one me or I am working with only two or three others.

Typically a team is a mix or good, crappy, dedicated and ambivalent people.

The main claim that I would make is that the *first* benefit of agile development the the power to focus people on the most important task that needs to be done and to pursue getting it done.

In classic XP, user stories that can be implemented in 1 day are written and prioritized. They are assigned to a pair of programmers who concentrate on only that task. At the stand up meeting every morning, people discuss their problems and any lack of progress.

This focus should allow even poorly preforming teams to be more productive. In a typically waterfall (or more likely a “no process” process) a crappy developer can be left to flounder for months between milestones. The results might be the same, but if you have even one competent developer to help out, this focus should help get better results.

I don’t believe you need to have a team of superstar developers to produces good software. Every team will have people who are more or less competent. Process is about getting the team to work and we should not be using crappy developers as an excuse

Now about your last point, “the choice of people is very important”, but this is a given, and it is very important in any methodology. If you put bad programmers on a project, not matter what the methodology is, then the work will take a lot of time, and the quality (especially the code quality for later maintainability) will be very low.

Again, this is only my opinion… Thanks for sharing.

Its really fun to watch how certain practices are implemented in their context. Standups running for around 1-hour, where everyone is questioned about their commitment daily and things like that, just to give an example.

I also think, once a manager has said ‘I have crap developers’, he’s given his intent pretty clear. There’s no trust/respect around. You can’t do agile on top of it.

There are better forms of management in this context. Things like ‘tell them what to do’, ‘monitor heavily’, ‘strong/multi-layered quality check team’.

On a serious note, I think a process should be tailored to the people you have. You can’t talk about either without considering the other.

Don’t do agile. Do what is best with your people.