We do not use UML, we are agile

I have heard many times the sentence(s) in the title and I can not argue with that. These are two independent statements, and it is out of my scope to disagree. Your group does not use UML. Fact. You are working agile: again: fact. What to argue about? The problem usually is the implied “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 again and perhaps get things better. After all agile is all about constant improvement.

UML is a tool that can be used different level, different purposes and there may be some place to use it even when you are working agile. There are several reasons why not to use and also why to use UML. My experience for the reasoning why not to use uml lists the same reasons as the article referenced above. You can see yourself that these argument 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 feeling for the poor decision not to learn the right tool. Learning new topics is hard and people are inherently lazy to learn new things. Very true. But this is what makes us, experts having good job. Are you an expert?

This is even worse when people learn new things (this time this is about UML) but learn it half-way and do not take the pain to use it properly. Here I list a few examples of extremely bad UML use that you have to avoid by all cost. I personally have seen examples of each.

Intimidate customer BA using UML

Once I met a software company who created vast amount 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 as such but were now knowledgeable. They just could not read UML and were afraid to admit it. They were afraid to ask, 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 caused significant headache for the company on the long run. Even though the architecture design is the responsibility of the vendor it is not without reason they are to be approved by the customer. After all: this is a cake baked by the vendor but is eaten by the customer.

Creating UML for the obvious

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

Diagrams UML like

I have seen many times diagrams that looked like UML diagrams at the first view. 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 in totally wrong ways. I have seen many times class diagram elements used to depict relations between modules. What seemed to be inheritance by the notation turned 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, soon they fiercely argued on a specific line if that is composition, aggregation or a simple relation. C’mon: focus on the real issue.

Conclusion

I do not tell you have to use UML. I do recommend though. Learn it a bit. But do not learn it to the extreme. Learn it to use it and not for knowing all the bits of it. (This is true for almost anything.) Do not be shy admitting if 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 for you and explain the notation. If they say: “hey, this is UML” you can bravely say: “Hey, I am the customer.”

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

It may happen you use UML “like” drawings, but do not be happy getting drowned into that 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 to be done. Use UML and be agile.