I have heard this sentence many times, and I can not argue with it. These are two independent statements, and it is out of my scope to disagree. Your group does not use UML; fact. You are practicing Agile; again, fact. What is there to argue about?

A problem is usually implied by having “because” between the two statements. If you say “We do not use UML BECAUSE we are agile,” then there is a problem. Not a life threatening issue, but still something to think about. After all, agile is all about constant improvement.

UML is a tool that can be used on different levels, and it certainly can have a place in an agile workflow. There are several reasons why you might or might not want to use UML. My experience for why you may not want to use UML lists the same reasons as the article referenced above. You can see for yourself that these arguments are also very lame. All of them can be summarized as: “I do not know it, therefore I do not use it.” All other words are just psychological self-confirmation to push aside the bad feelings for the poor decision not to learn the right tool. Learning new topics is hard and people are inherently lazy. But this is what allows the experts to have a good job. Are you an expert?

This is even worse when people learn new things (like UML) but learn it half way and do not take the time to learn how to use it properly. Here I list a few examples of extremely bad UML. I personally have seen examples of each.

Intimidating Customer BA Using UML

Once I met a software company that created vast amounts of UML diagrams and presented the architecture to the technical people of the customer in this form. This alone was not a problem. The issue with this was that the technical people were aware of UML but were not knowledgeable. They just could not read UML and were afraid to admit it. They were afraid to complain about flaws in the design and the architecture documents went approved without significant feedback. This made the architect’s life easier for the time, but they caused significant headaches for the company in the long run. Even though the architecture design is the responsibility of the vendor, it is not without reason that they should be approved by the customer. After all, this is a cake baked by the vendor, but it is eaten by the customer.

Creating UML Documents for the Obvious

This was very similar to the first one. UML was used to impress the customer. There was a UML model created for each and every class, even the simple utility classes, components, communication models and everything. Then the UML tool created hundreds of pages; redundant PDF documents with all diagrams that were imaginable generated from the model. Fortunately the PDF never killed trees by being printed.

UML-Like Diagrams

I have seen many diagrams that looked like UML diagrams at first glance. On the second glance, you spot some strange notations and then you realize that different diagram elements are mixed in a single diagram, and they are used incorrectly. I have seen many class diagram elements used to depict relations between modules. What seemed to be inheritance by the notation turned out to be a communication from one component denoted as a class to the other by the intention of the designer. The complaint was, “our drawing tool does not support component diagrams”. OMG! Use a different tool then! Pencil and paper version 1.0 ?

We Know UML

“We know UML.” The problem was that the members of the team knew UML differently. They sketched something on the white board discussing the architecture but instead of doing the effective work, they soon started fiercely arguing on a specific line about whether it was composition, aggregation or a simple relation. C’mon. Focus on the real issue.

Conclusion

I'm not saying you have to use UML. I do recommend it though. Learn a bit but do not learn it to the extreme. Do not be shy admitting that you do not understand something. Ask for clarification. If you lack UML knowledge and you are the customer, ask the vendor to setup a workshop to explain the notation. If they say, “hey, this is UML,” you can bravely say, “Hey, I am the customer.”

Do not generate UML documentation.  The PDF files will be too huge. Whenever you create a document, ask yourself the question, "who will read it and what is the reason to read it?" If you are the customer, be strict and limit the size of the documentation you are willing to accept and read.

You may use UML like drawings, but do not be happy getting drowned in the mud. Learn and strive for the correct use. Other professionals will understand your diagrams if it means what it is meant to mean.

And last, but not least, use UML as a tool and focus on the work that needs to be done. Use UML and be agile.