No. 5: I'll go to a class or read a book to learn the UML
Most books the teach UML diagram by diagram, element by element. That is one way to learn the piece parts of the UML. But you don't learn to write a great novel by reading a dictionary. During a job interview I was once asked by a VP of development why her people couldn't do object-oriented (OO) development. After all, she had sent them to a C++ course! OO and the UML are not just about the implementation language or the individual UML elements. You also have to learn an effective approach to apply the UML and OO techniques.
Courses can be a better approach (if taught by an experience practitioner and if the course is mostly hands-on problem solving). However, many people suffer from the "White Sheet of Paper Syndrome" afterward. They take the class, go back to their job, and try to apply what they learned. But they get stuck quickly. They look down at that empty white sheet of paper (or whiteboard or tool) and they realize that their real-world problem does not look anything like the contrived problem they worked on in their class. For example, ATM's, making tea, and library checkout problems used in classes never seem to reflect the complexities of the real world.
A total immersion program is the best way to absorb the UML notation, approach, and languages, if you are fortunate enough to be able to participate in one. They are rare, require companies to dedicate their people to the program full-time, and take quite a while (e.g. 2-3 months). But the results far exceed the investment. If you cannot participate in such a program, get a few good UML books, take a rigorous class that teaches the notation, approach, and (if you are a programmer) implementation language, and get your team an experienced UML coach to spend time working with your team. The coach is needed to fill in the blanks that courses and books do not address. Your coach will also help your team take all the theory they just learned and turn it into useful practices.
No. 4: UML is in the development mainstream -- all my people should know it
"Should" is the operative word. The UML "should" be mainstream and development teams "should" know it. However, that is not the case. In a recent survey
I ran, nearly 50 percent of the respondents said they new little or were just learning the UML. Also, only a few of the UML diagrams are being used on projects: mostly use case, class, and activity diagrams. These results reflect the results of other studies and the experiential evidence my colleagues and I see in the marketplace. This indicates that the UML (after all these years) is still in the "early adoption" phase, not the mainstream. Project managers should not fall for this misunderstanding. You never know; half your team may have fallen into misunderstanding No. 5 (above).
No. 3: The UML is a process / methodology
The Unified Modeling Language is just that -- a language. A standard language is a good foundation for developing common practices, processes, and methodologies, but a language is not a methodology. To be effective the UML must be coupled with an appropriate methodology (i.e. principles, methods, and tools), process, and implementation language, that all work together in a manner that is usable for your teams, in your particular development environment.
No. 2: Modeling isn't Agile
When people say this, what they typically mean is "Modeling can't be
Agile. So we're not doing it." Either they a.) don't really understand how to use modeling, b.) don't understand "agility", c.) just don't want
to model, d.) some of the above, or e.) all of the above. Remember that collaboration and effectively responding to change are goals of agility. It is much easier to discuss a diagram of your system at a whiteboard or with a modeling tool than trying to do so sitting in front of a multi-hundred page textual system specification. Plus with the current state of modeling tooling, finding all the elements of your system that may be impacted by a change to a specific element of your system is quite easy. Whether modeling is agile or not all depends on how you model. How broadly or deeply you model is your choice.
No. 1: We want to adopt modeling, so we'll just buy a tool
A "tools first" approach often runs into difficulties. Tools are created to provide broad functionality to a wide marketplace of users. How the tool vendor expects the customer to use the tools often conflicts with how particular companies or teams work in the real world. Thus if tools are allowed to dictate process, they can over-constrain your team and block their success.
A "process first" approach allows you to discover what really works for your project teams in your particular environment. Establish your approach to modeling first. Guidance for how the tooling should be used to support your process can then be established. And before you commit major dollars to a tool purchase, try out some of the free tools (http://rmaksimchuk.wordpress.com/2010/02/25/a-fool-with-a-tool/ ) and evaluation copies of the paid tools, to see how your teams will really use the tools. Your process must support they way your teams work and the tools must not get in the way.
I hope you enjoyed these 10 misunderstandings (and have not suffered from any in the real world). If you have additional "favorite" misunderstandings, let us know.