Here is the Manifesto for Agile Software Development (http://agilemanifesto.org/): 

To understand the four values, you have first to read and understand the end subtext:

That is, while there is value in the items on the right, we value the items on the left more.

Let's look at how this works by looking at each value in more detail:

• Individuals and interactions over processes and tools: In an Agile environment, we still have processes and tools, but we prefer to keep our use of them light, because we value communication between individuals. If we're to foster successful collaboration, we need common understanding between technical and non-technical people. Tools and processes have a tendency to obfuscate that.

  A good example is the User Story, an Agile requirement gathering technique, usually recorded on an index card. It's kept deliberately small so that we can't add too much detail. The aim is to encourage, through conversation, a shared understanding of the task.

In the same way, we should look at all of the following Agile values:

• Working software over comprehensive documentation: As a software delivery team, our primary focus should be on delivering the software—fit for purpose, and satisfying our customer's need.

In the past, we've made the mistake of using documents to communicate to our customer what we're building. Of course, this led to much confusion and potential ambiguity. Our customer isn't an expert in building software and would, therefore, find it pretty hard to interpret our documentation and imagine what we might be building. The easiest way to communicate with them is via working software that they can interact with and use.

By getting something useful in front of our customer as soon as possible, we might discover if we're thinking what they're thinking. In this way, we can build out software incrementally while validating early and often with our customer that we're building the right thing.

• Customer collaboration over contract negotiation: We aim to build something useful for our customer and hopefully get the best value for them we can. Contracts can constrain this, especially when you start to test the assumptions that were made when the contract was drawn up. More often than not there are discoveries made along the way, or the realization that something was forgotten or that it won't work the way we were expecting. Having to renegotiate a contract, or worse still, recording variances to be carried out at a later stage, both slow down and constrain the team's ability to deliver something of value to the customer.
• Responding to change over following a plan: When considering this Agile Value, it is worth drawing a comparison with the military. 

The military operates in a very fluid environment; while they will undoubtedly have a plan of attack, this is often based on incomplete information about the enemy's strength and whereabouts. The military very much has to deal with known knowns, known unknowns, and unknown unknowns. 

This is what we call a planning-driven environment; they're planning constantly throughout the battle as new information becomes available.

So when going into battle, while they have group objectives, the military operate with a devolved power structure and delegated authority so that each unit can make decisions on the ground as new information is uncovered. In this way, they can respond to new information affecting the parameters of their mission, while still getting on with their overall objective. If the scope of their mission changes beyond recognition, they can use their chain of command to determine how they should proceed and re-plan if necessary.

In the same way, when we're building software, we don't want to blindly stick to a plan if the scope of our mission starts to change. The ability to respond to new information is what gives us our agility; sometimes we have to deviate from the plan to achieve the overall objective. This enables us to maximize the value delivered to our customer.