What they also failed to realize, which was also true then, is that the person I need a face-to-face conversation with is neither in the desk next to me nor at my employer's site the next country over: he was in my desk last year, works somewhere else now, and didn't write anything down because Agile™ told him it wasn't ‘effective’.

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

I love my job :)

* "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.

On top of that, they were looking for brevity over writing a novel, considering that it came out of a group of like-minded people over a long weekend.

They also fail to realize one of the most important bits of the Agile Manifesto is you're supposed to tear it apart and over time redesign it to work for your own org.

Anyone who just says "We do X, because that's how Agile recommends it" is not actually doing Agile.

I actually still think face-to-face meetings are the best way to communicate. That does not, however, outweigh the disadvantages of forcing people to commute to an office.