1. This code doesn’t need commenting.
2. This shouldn’t take long.
3. I can do it better myself.
4. I’ll fix this later.
5. It’s only a small change.
6. It’s not a bug.
7. I know what I’m doing.
8. I can safely skip that test.
9. I’m using <NAME OF FAVORITE PROGRAMMING LANGUAGE HERE> so we’re good.

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

(While there is value in the items on the right, we value the items on the left more.)

People will remember slipped dates but not slipped features. If deliveries are made to meet deadlines, even if the deliveries do not include all the promised functionality you are less likely to get into trouble than if you had delivered all the functionality but at later date. If you regularly deliver production quality code on promised dates end users and customers will tend to be forgiving, even if some planned features and bug fixes are not delivered on that date. For some end users, getting anything on a regular basis, and not necessarily everything, can leave them delighted.

A software system will reflect the organizational structure of the team developing the software. If the development team does not communicate well then the components of the software system will likely also not communicate well.

Software evolves or dies.

Users do not know what they want until they see working software. As users interact with a new software system they become more knowledgeable about system potential and functionality. The iterative review and suggestion process leads to further unpredictable discoveries.

If you don’t attack the risks, the risks will attack you. There is some amount of risk in every project. Further, ignoring risks does not negate these risks, only that they will not be taken into consideration and managed. If these risks are not monitored they can evolve into real problems that are likely to “attack” you. When something has risks, these risks should not cause you to avoid pursuing the project, nor to pursue the project and ignore the risks and what they can become.

Software development is unpredictable and that specifications and requirements will never be fully understood. When you are creating something new, regardless of the amount of similarity to what has been created before, it is impossible to be certain of all the needs and constraints. We can forecast with varying degrees of accuracy, and should caveat all forecasts with a degree of certainty, but we really cannot predict precisely all the functional and non-functional requirements.