Every project and situation is going to be different, so it is impossible to provide a step-by-step solution to your problem. I've tried to outline some of the common approaches I've used or seen applied to various situations, particularly when dealing with a legacy product that was not developed using sustainable techniques.
Identify Key Architecture Battles
Do an architectural analysis, where you identify things such as poor structure and areas with a large number of defects. Every time you modify these sections of code, even if only for a minor change, consider doing some refactoring work in addition to just making the changes, even if this means setting aside extra time to make the changes. Be sure to add tests at least for the new code, and if you can, identify the key interfaces and add tests for them.
In your iteration planning sessions, write up some cards for the refactoring work. Users, product managers, and managers are in my experience very supportive of refactoring work if they are involved in the process of helping to set overall priorities and understand, at least at a high level, the purpose of the refactoring work. The visibility that this gives to the architecture of the product is good for the entire team, while at the same time ensuring that architectural issues are weighed against the feature work that users are demanding.
Get Your Defects Under Control
Hopefully, you should now be convinced that defect backlogs are a bad thing. Introduce some visible metrics, and possibly an ambitious goal such as HP's "10x reduction goal" [Grady 1997] to get people focused on the problem. Then, work hard toward a culture built around defect prevention and working software.
Collaboration with Users
For many organizations, one of the most difficult steps in introducing agile development is getting timely feedback from users. This is an ideal problem for senior management in the company to get involved with, to set up the necessary user contacts and also to get everyone in the organization focused on the need for greater user contact.
Training is a crucial part of moving from an unsustainable to sustainable development culture. Training needs to be considered for the entire team, ideally at the same time. In the early stages, using an external source (consultant or training organization) for training is usually required, because even if someone inside the company says the same things as the consultant, the consultant will often be listened to more, simply because he or she is from outside. However, once the initial training is complete, it is highly desirable to set up an internal training program, where people inside the company are given the opportunity to train others on topics they are knowledgeable in.
Group Refactoring Exercises
An unorthodox idea that I've seen work is a competitive refactoring exercise. Pick a piece of code that has many broken windows in it. Then, get a bunch of people together in a conference room and do a pair programming exercise to refactor the code. Consider pairing people together who don't work together too much. Use a projector to review the solutions that each pair came up with during the day and discuss the pros and cons of each. Optionally, an award could be given for the solution the group likes the best. This exercise is time-consuming, but it helps everyone understand the difference between good code and bad, and the result can often be applied in the live code the next day. Also, the discussions are valuable for everyone, and the whole process can be fun with an underlying thread of competition.
The Work Environment
One factor that is often overlooked when introducing change is the impact of the physical space the team works in. If you possibly can, change the physical space that the team operates in to facilitate collaboration and reduce unnecessary interruptions. Sometimes, simple changes can make huge differences in terms of productivity, and the highly collaborative nature of agile development demands a work environment that does not inhibit collaboration and free communication. Too many organizations are penny wise, pound foolish and skimp on equipment that will increase productivity simply because the equipment is considered too expensive. Here are some ideas to consider: