Many teams don't develop software in a professional way. Thats why I write and talk about your duties as a professional software developer. I basically get two kinds of reactions to that. One group agrees with me, at least on the basic idea. But the other group basically claims they aren't able or aren't allowed to act professional.

I can relate to that. I was stuck in projects where I just wasn't able to work professional. I wasn't able to write test. I wasn't able to write clean code. I wasn't able to establish what a piece of code needed to do, before I started coding it. And yes I blamed my employer or more often the customer for this.

I was wrong or stupid, possibly both. You decide.

It is stupid to hope for your customer to tell you: "Hey, just take an extra month of time for that piece of software in order to write some extra tests". Why should your customer do that? If he would know how software development works he wouldn't ask you to do it, right?

So if you are convinced that change needs to happen, it is up to you to make it happen. Here is how it might work.

1. Find some time for your personal skill development. You have three options:
   • Get an official time budget during your work time for that.
   • Find a not so official time budget during your work time for that.
   • Use your free time for it.
   
   
   
   While the first two are nice, I don't think there is an alternative to the third one if you want to get anywhere. In this sense a Software Developer is like an artist. You don't stop being an artist after leaving your studio. If you are not willing to invest your private time in your personal skill development, you should get used to being a mediocre software developer.
2. Find the most pressing need in your software development process. What is the single thing that you and your team would benefit from? A version control system? A build script? Tests? A Continuous Integration System? Code Reviews? Find the most basic, simple solution you can think of to implement it. At least for a Java Environment there are free solutions for almost every piece of infrastructure software you might need. If you don't have a development server, set up the systems you need on your one development machine. You can setup a tomcat without admin privileges, so you can use all of the web based stuff available. The important thing to remember is to aim for small changes. If you bring the development to a full stop for a week your boss will notice and she won't like it.
3. Use and practice the new practice until you are as fast with the new practice as you have been without it before. If the other team members are supportive, use and practice together. Expect this to take a looong time at least for the things that directly affect your coding practices. For example: When you never wrote a unit test before you probably won't be able to switch to Test Driven Development within a couple of days. You migth start by writing tests in really simple cases. You will start writing tests that are too slow, and too brittle and which will actually be a handicap. BUT you will learn how to write lots of tiny tests. And you will learn how to structure your code in a way that makes it easy to test. And finally you will realize that switching to TDD isn't a problem anymore.
4. When the new practice helps you in an obvious way, then let the sceptics know about it. But don't make it a big thing. Don't force the new practice onto anybody until you have a strong support in the team. Just make it your own personal standard. Prepare to honestly argue, why not using the practice will cost more time. The argument will probably run along the lines: I need 10 hours for the task, including a healthy dose of unit tests. If I exclude the unit tests, I save about 2 hours, which I will need for additional support efforts every month. Make sure your estimates match your arguments. Make sure your estimates are realistic. Exaggeration or even lies will just damage your cause.
5. Know to use the right argument for the right people. Developers might be intrigued by using the same Continuous Integration system as original signers of the agile manifesto. Managers won't. Managers might get interested when you tell them about two dozen bugs found in the system by your automatic tests, but they really get excited when you can translate changes in your development practice into Dollars, Euro or Yen. We might not like it, but that is just the way it is. So don't tell them it is cool that you can now build the system on a click of a button. Tell them how you needed 1 hour manual work before and 10 seconds now, and how that saves Dollars every day. Don't just translate your arguments into management speak. Think in management speak. Although they are annoying at times, they make sure the companies gets the money needed to pay your salary. So everything you do should be aimed at maximizing the productivity of yourself, your team and the company. Of course defining 'productivity' is a completely different story.
6. If it doesn't work, think hard about what YOU can change. Nobody will change their opinion because you think they should. The only chance to change behaviour is to act. Don't expect to succeed on the first try. It might take many attempts until you succeed in creating a respectable TestSuite and probably even more until anybody notices. So be persistent.
7. The grass is always greener on the other side. Switching jobs might be the right thing to do when you get a great offer, or if your current job resists all attempts to change it to the better. But consider this: When you have a real interesting software development position to fill. Whom would you consider? The guy complaining about the last job where he wasn't allowed to work professionally and therefore hasn't any real experience in writing tests, never worked with a CI system or a build tool. Or would you prefer someone who introduced testing into a project team, show initiative by setting up hudson on his own machine and is now looking for an employer who supports this kind of attitude. I know what kind of coworker I am looking for. So make sure you tried to make your job a better one, before you leave.