What would be your absolute minimum “documents” you need to have in hand to start a project on the right foot?

Hello fellow engineers,

I've been questionning lately how I document and plan the start of new software projects. I'm recently out of engineering school (it's been 2 years), but have been working in the industry for many years before as a developer.

I'm trying to stay extremely by the book and apply what I learned in school to software projects, things like System sequence diagrams, Domain models diagrams, DB Diagrams, lots of UML diagrams, documentation about the architecture, documentation about the processes, documentation about the requirements, etc… but I feel like most of these are waste of time. Like sure these might be useful at the immediate beginning, but as we are "AGILE", clients might priotize different features or want something else entirely. The cost of keeping all of these documents are way too high and we're removing time for devs to actually work on the thing. Most of the time the documents don't even help the devs because they are always out of date and with deadlines and changes we might not have the time to change them.

My school might have the right mentality for us learning those things, but they are not adapted to an actual working environment. Most of my engineer colleagues do extremely little documentation and mostly manage to "wing it" and mostly get away with it by delivering something fast. They don't talk about the quality of the code thought.

So I'm looking for documents that are easy to update and provide real value to devs during a software project.