I saw two articles that I thought were going to be pretty promising, but was partially disappointed. I approached the first, Death by UML Fever by Alex Bell, with the attitude that someone would be complaining about UML. I was expecting to hear someone explaining why UML was soooo bad and why nobody should use it. I have to say that I was actually surprised - both good and bad. The article didn't detail why people should stay away from UML. As a matter of fact, the article didn't say much at all. It was clever, though. The somewhat whimsical way it depicted the “fevers” was amusing, but I found myself looking for an answer - a remedy of sorts - at the end.
What I would have hoped to see was an explanation of the benefits of UML and how they should be applied. In its simplest form, this...
UML is a communication tool. And, just like any other tool, you only need to use it when it makes the job easier - whether now or in the future (the future being the key). For instance, cell phones are great; but, would you use your cell phone to talk to other team members who are sitting at the same desk as you? Probably not. UML should be treated the same way. My suggestion would be to use the most basic of UML features at a minimum - class diagrams. When a question arrises about how to get from point a to b, then you should highly consider creating an interaction diagram of some sort. For user-architect/designer relationships, use activity diagrams; for architect/designer-developer relationships, use sequence diagrams. UML models/diagrams should only be used if they clarify the problem/solution at hand. Using these diagrams will help you find bottlenecks, inconsistencies, and other implementation issues. Finding these issues early can save innumerable hours of development time. Don't go on a “manhunt” for issues during design time, however - this will bring on the UML fever mentioned by Alex. If the users, designers, and developers feel comfortable with the existing models/diagrams, then move on. If a question comes up later, stop, discuss the problem, and take the 30 minutes to map out a solution - or even just a description of the problem. The point is to answer the question, whatever it may be, so that it will not come up again - even if you get a new team member.
Key tenet: If someone asks the question, create a model/diagram explaining it.
I could go on explaining when to, and when not to use UML, but I'll save you the time.
The next article, The Fever is Real by Grady Booch, tried to validate the existence of UML fever and explain why it was created. I think this was helpful to get a bird's eye view of the situation, but I still felt like I wouldn't know where to go next if I was affected by UML fever.
The answer is not to quit. The answer is to stop. After you stop, take a look at what you have. Don't waste time cutting back or adding more detailed information unless it is absolutely necessary to reduce confusion. If you've been afflicted by this fever, then your team will already be in a state of confusion, so try to minimize that as much as possible. I suggest having a stakeholder meeting to find out where you are in your process and where you need to be to move on. If everyone is comfortable with where you are and where you are going, then work on the next step/phase in your process. If you are worried that you shouldn't move ahead, then give people time to review while slowly making your way into the next step/phase. Eventually, if you're using my suggested tenet, then you should find yourself on the right track.
There are countless ways to actually cure yourself of UML fever, but the first step is diagnosis, as Alex and Grady mentioned. Whatever you decide, be sure to have a strong understanding of how/why UML will help your project before going too far. Good luck.