I've also seem to get involved in seemingly endless battles to improve the development methodology. It is something that interests me as much as the development itself.

What I've found is that every environment is different, and the things that work best are often informed as much by the business environment (e.g., how much does a bug really cost?) as it is by the technical environment and culture.

So while I can say that team programming, peer review and regular shotgun meetings are what I've found to be the most useful, I offer the following advice:

• Be prepared for the changes to take a long time to implement and gel amongst the team. Six months to a year would not be atypical. Let the business people in the company know what your ideas are, but also let them know that your ideas will take some time to implement properly and for the results to show. You will need the buy-in of the suits over a long time horizon, so manage their expectations: You are not going to cut development time in half overnight, but you should see a gradual but consistent improvement over time in coordination, estimation, output, and quality.
• Any methodologies do need a strong advocate. Every formal process takes time, and there needs to be a strong and informed individual to push back when business decision makers want to take shortcuts which may appear innocuous in isolation but which breed a culture of sloppy work habits.
• Don't be too inflexible. Every environment is different, and one development technique may work well in one shop and not another. Keep trying things, promote an environment that encourages constant and positive feedback, and keep the things that work and discard those that don't. Don't rely on a single development methodology, though you may favor one over others: No single development methodology is a silver bullet. Inform yourself and pick and choose.