User Stories

Like use cases, but much less formal, more like the original intent of a usecase. The current usecases use templates and more formalized format making it loose sight what is really important. Nevertheless the additional detail may be helpful for actualy implementation, and hence, perhaps added as part of an implementation document of that feature.

Weekly builds, and small iterations

Deliver early and deliver often. Start delivering executable code and executable architectures is the message here.

Architectural Metaphors and standardized naming schemes

For well known ideas use well known terminology and borrow well known architectures.

Collective ownership

We all work on this code. It is an external entity and we all can change it.

Coding standards

Got to make it a habbit.

Simple design

Keep designs and architectures simple and understandable. This ensures worker empowerment and hence supports his bill of rights.

Refactoring

A system that does not know how to evolve can never be great. You should measure the success of a project by how well it can change itself in the next release.

Testing

A software system is no better than its test cases allows it to be

Pair programming

Quality compensated with price. For higher quality systems like billing systems it might be essential that two people may have to do this. They can collaborate on design, testing, and coding.

Continuous integration

Provides developers a latest working copy all the time. This again empowers the developers with productivity.

Onsite customer

Knowledge repository. Testing. Purpose.