This is a poor understanding of "comprehensive documentation."
You should absolutely be keeping documentation. However, you should not require hundreds of pages of specs and design documents before a single line of code is written.
Instead, documentation should be written at the same time as the code, and should follow what is actually needed for and by developers and the organization rather than being subject to a "gate".
It's about writing the right documentation. Some of that documentation is harder to write: For example, writing a specification that can literally run against the software, like in behavior driven development. (This is one of many potential tools. It may not be applicable for you.) It may look like a wiki. It may look like a set of UML diagrams and a formal spec. It depends on the team and the domain of the problem.
The problem that the manifesto was talking about was one of documentation as a deliverable that was not properly updated and only written to pass a requirement of the process.
I wish the agile manifesto had included a bullet point that said 'favor working code over comprehensive documentation%'
% where working code != the code will work if all stars align and no invalid data is input and comprehensive documentation != a single typed character more than what is forced out of your tortured fingers by those who have to support your code at 2AM
* "while there is value in the items on the right, we value the items on the left more" suggests that you should do enough of the items on the left such that the job gets done.
* "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." implies that the ops team also needs to be given the environment and support they need from development.
* "Continuous attention to technical excellence and good design enhances agility." where "technical excellence" implies an understanding of working code that isn't dependent on valid data.
* "At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly." means that if ops can't do its job, then the development team needs to reflect and adjust its behavior accordingly.
So, sadly, they tried. We just went too far in the other direction in some organizations, and that needs to be stopped. If it isn't working, change it - agile shouldn't be in the way.
This is a problem with reading documents without understanding the time and context they were written in. If you’re a twentysomething developer who’s never worked in a process and documentation-heavy organization, the agile manifesto will sound like it is advocating something it is not. It was a reaction to the prevailing thinking of the time.
You should absolutely be keeping documentation. However, you should not require hundreds of pages of specs and design documents before a single line of code is written.
Instead, documentation should be written at the same time as the code, and should follow what is actually needed for and by developers and the organization rather than being subject to a "gate".
It's about writing the right documentation. Some of that documentation is harder to write: For example, writing a specification that can literally run against the software, like in behavior driven development. (This is one of many potential tools. It may not be applicable for you.) It may look like a wiki. It may look like a set of UML diagrams and a formal spec. It depends on the team and the domain of the problem.
The problem that the manifesto was talking about was one of documentation as a deliverable that was not properly updated and only written to pass a requirement of the process.