It is important to understand that Agile Manifesto is a criticism of ways of work that were dominant in the time it was written. When you understand how software development was done back in that time, things start making sense.
Customer collaboration over contract negotiation
Back in the days, it was (and sometimes still is) perfectly normal practice for customer and the builder to sit down, and write down contract along with detailed specification. That contract would go into details of what and when the work should be done. The customer would then disappear, only to appear again when the work is supposed to be done, expecting to get software as defined in contract. Most experience tells us this cannot work. Instead, manifesto tells us that we should strive to involve customer in the development as much as possible. And collaborate with him on daily basis in building the software.
Responding to change over following a plan
Often, included in the contract above, would be detailed plan on how the implementation would progress. It would define phases and milestones and specific dates when those phases end and begin. This meant, that even if work in one phase was not yet finished, if plan told you that phase was meant to end, it would end. Also, once you were in a phase, it was difficult to go back to previous phase. So if you were in implementation phase, and found a design defect, it was not possible to go back to design phase to fix that problem. There was some flexibility, but that was often superficial or expensive. Of course, this was found out not to work. Manifesto tells us that this approach is way too risky and that we should structure our development plan in a flexible enough way that when problems are found, the plan can be changed to accommodate those problems.
