For a few months, I've been working with a new team in a new company. The company offers some web services and the team's role is to develop and maintain those services.
Problem #1: the team is not a team, it is a set of individuals. They do not collaborate with each other. Everyone works on his own piece of code in the way he likes, with his own conventions and methodologies. The closest thing to collaboration I've seen so far is: "I've finished implementing this feature, now you can start building something on it".
Problem #2: There is no modularity. Well, actually, each developer's work is in its own repository, but those repositories are highly heterogeneous and mix different stuff (often reinventing the wheel and duplicating code).
Problem #3: The development practices are really ancient. They know the word 'agile', but they don't understand the concept behind it (probably because they've never tried it). There are no code reviews, there are no tests, software is really hard to configure and adapt. The overall development process is slow and inefficient.
There are many other defects but they are probably consequences of the three problems listed above. In short, the codebase is a mess
How to deal with it?
Working here, I've quickly noticed these problems, and at first I decided to drive by inspiration: I've worked on my first project with some agile development practices and the feedback has been good.
However now I'm in a situation where I'd like to touch other people's code/practices and I can't drive by inspiration, because I need their collaboration.
I tried to make them understand that they're a team that is building a product and they're not individuals working on their own projects. However they couldn't understand what I meant and simply ignored me.
Now I'm thinking to change my approach: I want to explicitly state that they're making mistakes, analyzing each mistake, their causes and proposing solutions. I want to start from the low level (e.g. "this piece of code is slow/wrong/inefficent") and then slowly move to the high level (e.g. iterations vs. waterfall). But I fear that they would think I'm attacking them, which is not the case.
Is it the right approach? How should I proceed?
EDIT 1: Based on your answers, clearly this is the wrong approach. Starting from today, I'm going to continue leading by example and explicitly point out the benefits brought by my methods. (Untill now, I have constantly asked for feedback, but actually have never asked explicit questions like "hey, do you like the fact that I have written acceptance tests? Do you think they will improve the overall quality of the project?") Let's see if it works!
EDIT 2: As I said, I started leading by example and speaking with teammates and with managers. The result? I've been nominated "master reviewer", i.e. my role now is to actively participate in all technical discussions, give suggestions on the architecture and establish new approaches to the development process.