OK, to start with, there are very few "bad" teams. If they really are bad, the best way to turn them into good is to replace those bad elements with better people, and get things going smoothly. What I mean by a bad team is one that has poor morale, no confidence, poor quality in their product releases, lack of on-time delivery, and a generally lousy attitude towards their company and their products. This isn't as rare as you would think. While the extent of the "badness" differs, I've joined companies where the Development team was just way out of kilter, needed focus, and generally required attention to get things back on track.
Sure, there can be specific causes for a bad team, such as poor software design, lousy architects, impossible deadlines, or lack of respect from the rest of the company, but mostly the bad teams are self-generating. They don't care enough to change, or if some of them do care, they can't find a way to change. That's where management (me!) has to take the lead and help.
In general, team attitudes don't change quickly. It's a slow process that involves several factors, one or more of which may be at play in the particular circumstances. The first target for me is the software design itself. Is it sensible? Can it be done? Is there a fundamental flaw in the design that means it will never work right? If I can identify issues with the design, and straighten them out, then that's a key first step. Nothing discourages a developer more than knowing what he's sweating over will never really see its full potential because the larger product is just plain flawed. A good architect can help clear things up, but generally the design is flawed because a bad architect had at it. Replacing that architect (either from the company or changing their job description) is a key to fixing the bad architecture issue.
The second target for me is to look at the code development process. Is there one? Is the code handled safely, checked into a source code control system, and tracked as to reasons why changes are made? Are unit tests performed to make sure the code does what it is supposed to? Is the code tested by someone other than the developer? (Is the code tested at all, is often a key question!) Once tested, is there any integration testing? What's the QA process? Until the code development process is laid out, understood by all, and followed by all, then there's too many possible variations that can lead to errors.
The third target is deadlines. Are the demands on the development team so unrealistic they can never achieve success? Who sets the deadlines, and how are they managed? End-to-end tracking and control of projects is a key to successful software development, and if no one does this job then someone has to.
The fourth target is work environment. Are the computers sufficient for the task (both on the desktop and at the server end)? Are the tools being used by the developers and testers adequate to the job? Would changes in software or hardware help? Is the office a good place to work, or does it feel like a sweatshop? What about amenities?
The fifth target is the staff. Are they the right people for their job? Do that have the skills needed? Are they paid fairly for the job they are doing? If not, what can be done (even if longer term)? Is there a clear management structure so someone knows who to report to? If not, then put a structure in place.
The final target is communications. Does the entire team know what's expected of them, what their deadlines are, who the customer is, and what the goals of the group are short and long term? If not, then it's time to have an All Hands and start a regular update meeting cycle. An educated and knowledgeable work force is much happier than one that has no clue what their role in the big picture is!
All of this sounds like a lot of work, but it really isn't as many of these things are obvious after just a couple of weeks at a new company. The group dynamics are typically plain to see, and quiet conversations with the staff reveal underlying issues that are not so obvious. Usually, I spend the first two to four weeks just observing and learning, gauging what's working and what isn't and comparing it to previous, successful groups, and then come up with a plan to get from where the group is now to where I need them to be. That may take months, sometimes even a lot of months, but it is a clear and definite process that needs to happen. The result, bit by bit, is a better workforce, and (gasp!) a good team.