In Agile Software Development, Uncle Bob once wrote his First Law of Documentation "Produce no document unless it's need is immediate and significant." As has been typical of such comments in the Agile world, this has been misquoted and misinterpreted many times. So he later went on to clarify.
Agile Methods require two kinds of documentation: Requirements and Design Documents. All other kinds of documents are optional within Agile Methods; but optional does not mean absent.
Requirements. In Agile Methods, the requirements are documented one iteration at a time. Requirements are often identified long in advance of their development, but they are not fleshed out until the iteration in which they are developed begins. Moreover, they are written as automated acceptance tests. Other kinds of requirements documentation, such a narratives, workflows, and storyboards may also optionally be created.
Design Documents. In Agile Methods the design is documented by creating unit tests using Test Driven Development. These unit tests are working examples of how to use each part of the code. Other kinds of design documents, such as class diagrams, interaction diagrams, state charts, ER diagrams, etc. may optionally be created too.
Note the last paragraph in particular. It is sometimes ridiculous for developers to write documentation for other developers in English. Never forget that there is another common language that developers speak: code. Unlike English, code is self-validating.
Using unit tests to document the intent of the application code is a brilliant way of writing documentation. Why? Because they're guaranteed to remain up-to-date.
Further, and perhaps more relevant to your situation, he writes:
Documents that the development team decides they need, are simply created as and when they are needed. Documents that the business decides they need, and that the development team does not need for their own purposes, are written as story cards, and estimated, planned and scheduled as all story cards are. If they never get selected for an iteration, then they must not have been all that valuable to the business. If, however, they get scheduled for an iteration, the business must have considered them important enough to schedule.
This is a technique I use all the time for figuring out what is genuinely useful documentation. If the development team feels they need it, just give them the means (a wiki) and they will write it, without being asked. If the business feels they need it, queue it up as a job next to everything else, and see if they decide they need it more than they need other work.
similarly to when someone asks about good OOP techniques and gets directed to design patterns and SOLID principles.
Similarly? When we are presented with a technical problem, we can point to the better practices & principles. But, we don't know your team, how could we know what would work for you guys?