Your highest priority is to take no initiative for which you could be blamed. Taking no initiative at all would be even better.
Changing requirements are a pain in the ass, moreover late in development. Let it know to the customer and make him pay dearly for just thinking about change.
Do not deliver working software frequently, because this could make the customer change his mind (see above).
Business people and developers must work together as fewer times as possible throughout the project. They both have other important activities to carry to waste their precious time in meetings. Furthermore, they do not speak the same language.
Build projects around solid processes because you know that individuals are even more unreliable than software (and you know what you are talking about).
The safer method of conveying information to and within a development team is by a formal document approved by the steering committee.
Project reports and billable hours are the primary measure of progress.
Good processes promote heroes. The sponsors, developers, and users should be able to recognize that they face a difficult challenge.
Recognition of technical excellence and good design allows developers to think that they are free creative artists (and does not burden the project budget).
Complexity - the art of maximizing the amount of time needed to understand your design and code - is essential to define your value as a developer ( and to protect your job).
The best architectures, requirements and designs emerge from nowhere and should be send back there as soon as you detect them. Maintenance and evolution is where money is earned!
At regular intervals, the team should meet to eat pizzas and drink beer. It helps developers to forget that they are working in a bloody software development project and confirms that the management really cares about people. (they do not mention pizzas and beers in the other manifesto, think about it...)
Messages
