The question is ...

  

When your team has a meeting or do you discuss some functionality with a fellow developer, do you use the diagrams?

In case of affirmative , then use must be daily, so it is rewarding to keep documentation up to date.

Negative case, diagrams were probably only meant for initial understanding or to meet customer or management expectation, not worth it ; work is more than the benefit harvested.

Considerations

If the source file of the diagrams is versioned along with the source code, then it is easy for any team member to update the diagram and synchronize the project with SCM.

UML diagrams need not be a 100% accurate reflection of the code. In many cases, I avoid placing attributes in classes so as not to compromise the internal structure.

But what often happens is to use the UML to represent the system database model. I do not really agree with that. There are more appropriate tools that allow you to do an MER (Entity-Relationship Model) and already synchronize the diagram with the database.

The easiest (and cheapest) way would be to make class changes (software running first) and then reverse engineer it to generate class diagrams and the like. There are several tools on the market that do this for you.

I think that it is necessary here to point something to reflection that has already been described in several articles, that UML is not documentation .

In the concept of "agile" development documentation is a mere aid in the process (user story is a great example).

If you are in the "agile" the idea is that the documentation is collaborative, that is, it grows according to the need and with the collaboration of all after team scrums (eg daily scrum or sprint planing).

The important thing is to deliver value to the customer. If the documentation is an artifact to be delivered too, you will inevitably have to update it, but not necessarily at the exact moment a change was identified.

If the change will impact the next sprints, then it is worthwhile to update the documentation.

Now, if the documentation is not a deliverable artifact and if the changes do not impact what will still be developed, I suggest taking it just as a lesson learned.

Remember that the focus on agile methodology is delivering value to the customer. So they do not approach documentation, although documentation can be a deliverable that generates value.

Make your own judgment.