I've asked this question a few days ago about how much documentation should be made and now I realize I may have been asking only half of the question.My goal is to promote some sort of documentation in order to increase continuous knowledge inside the team.My team is working mainly on server-side services which extends proprietary devices which are distributed locally (national not global)In addition we supply APIs and administration web apps to those services.What would be the best types of documentation for my team? Should we focus on DFDs, sequence diagrams, class diagrams, just plain text... ?Are some documentation methodologies better for specific industries or are there some  which are just a waste of time?I fear this last question would be put down as too subjective, but I do hope there are some standard answers for this question, similarly to when someone asks about good OOP techniques and gets directed to design patterns and SOLID principles.
How should I choose the right documentation for my team?
documentation
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.