The diagram is less important than the conversations you have when communication concepts between the various stakeholders in a project. After years of developing software, I've found myself trying to capture information diagrammatically even less in recent years than I used to when I was just starting out. I might draw up a few simple use-cases on a whiteboard when discussing concepts, and I'll often resort to a simple but classing flowchart if I am trying to gain some understanding about how a customer wants a system to work, and if I am particularly concerned, I'll use the camera on my phone to capture the image on the whiteboard to help me remember specific things.

Heavily documented up-front design isn't very lean. It discourages change and fixates your thinking around a single plan of attack that might end up totally wrong for the project overall. You want to be able to defer as much of your design as you can to the last minute, to reduce your chances that a big change will mess up your designs and schedules later on. This is not to say that UML shouldn't be used, but rather that it should be used sparingly, as a means to improve the communication of concepts, and not as a means to define the systems you are intending to build.

The diagram is less important than the conversations you have when communicating concepts between the various stakeholders in a project. After years of developing software, I've found myself trying to capture information diagrammatically even less in recent years than I used to when I was just starting out. Nowadays, I might draw up a few simple use-cases on a whiteboard when discussing concepts, and I'll often resort to a simple but classic flowchart if I am trying to gain some understanding about how a customer wants a system to work. If I am particularly concerned, I'll use the camera on my phone to capture the image on the whiteboard to help me remember specific things.

Heavily documented up-front design isn't very lean. It discourages change and fixates your thinking around a single plan of attack that might end up totally wrong for the project overall. You want to be able to defer as much of your design as you can to the last minute in order to reduce the chances that a big change will mess up your designs and schedules later on. This is not to say that UML shouldn't be used, but rather that it should be used sparingly, as a means to improve the communication of concepts, and not as a means to define the systems you are intending to build.