Working software over comprehensive documentation
Which, to me, means it is better to spend time on making more value, that is, time spent making software work than on documentation no one is going to look at.
I'm afraid this is one of the parts of the manifesto that I take the most issue with, and I'm going to have to use you as an example why. There are many people who interpret that line in the same way. I'm not sure whether that's the same way the manifesto's writers were thinking when they wrote it. I hope not, and I think there's a reason that it might not have been, but as I've said to other defenses of the manifesto, they didn't bother explaining what they meant, so they're either in agreement with or responsible for this attitude when people use the manifesto as justification.
A lot of developers don't like writing documentation. They start finding reasons why they shouldn't have to. Managers also don't particularly want to do it, because it would seem to add time to the development process without making the software any more capable, and if the developers aren't going to do it, then you'd have to hire other people to do it, and that's expensive. Too bad for both groups because it is needed, and they should both know that. I'll tell you who suffers when the documentation's insufficient:
1. The users who read the documentation in order to use the software and get their job done.
2. The users who don't read it, but when they screw something up, can be referred to it, read what they should have done, and use it properly next time.
3. The trainers who need to learn how to use the software in order to teach users, but don't use it themselves. Winging it means training people in at best an inefficient and at worst a wrong way.
4. The support staff, if you're lucky enough to have them, who explain to users how something works even if they don't use it full time themselves. This also includes the tech-savvy colleague who gets a lot of routine questions from the less knowledgeable users.
5. Developers in general when they need to know what behavior is expected, so they know whether a certain change needs to be written differently, communicated to users, or expanded with multiple options.
6. New developers who need some way to learn what this project does and how it does it that's a little faster and more reliable than figuring out where the main function is and trying to read it like a compiler.
7. Me, as an established developer, when I want to help the new developers learn but don't have enough time to hold a complete course on it.
8. Me, as an established developer, when I need to teach someone in great detail or they'll be unproductive and our manager gets unhappy, but the lack of documentation means I have to spend a long time doing this, which means my code production decreases, which means my manager gets unhappy.