Document and document again

The document is also a document. I think it is very good to write a section about the document in Agile modeling.

Excessive documentation due to fear of losing everyone

Many organizations fear losing their software development teams, because once all or most of the team leaves, it is very important and often has no chance to leave with them. Common Causes of team loss include:

Competitors have dug teams from you to start their own projects.
Some developers often jump around and never stay in any company for a long time.
After the team completes the project, you intentionally disband them.

To solve this problem, the Common Strategy of senior management is to require a large number of documents. They believe that once this team is lost, they can simply form another team and hand over the documents to the new team. This method sounds good, but it is often proved to be useless in practical work. First, although the document may be helpful to the current situation, new teams are unlikely to trust it. They would rather get a "terrain direction" about the system through it ", then drill into the code to obtain details. In other words, they may only use detailed documents to include a small part of the overview document. Second, this policy often becomes a self-fulfilling prediction, Because you force developers to write excessive documents, fearing that they will leave, because of your bureaucracy, lack of trust in them, and lack of attention to software development, they will really decide to leave.

In this case, I will work with the person requesting the document and try to work out a more agile approach. In my experience, high-quality source code supported by concise overview documents and appropriate contract models can provide a good enough System Description for developers who need to maintain and enhance systems in the future.