Our customers are very important to us.  We will do everything reasonable to make our customers happy.  If we cannot satisfy or customer, they will fire us.  If our customer is unreasonable, we will fire them.

Our software is not overly complicated;  it is easy to understand.  If the architecture takes an hour-long meeting to explain, it’s wrong.

We operate as a team.  We communicate.  Occasionally, we will argue (respectfully) because we all have different opinions.  That’s ok. We are not offended by it.  If someone on my team needs help, I readily volunteer to help.  For you manager types, read this article of stages of team development to help your team get to the Performing stage.

We commit completed, tested, demonstrable code.  What does that mean?

• We don’t break features up into a bunches of unrelated stories.  We are committed to getting the feature done by the end of our development cycle (iteration/sprint).
• We don’t commit half-assed ideas to the trunk in lots of little piece.   Every source control system out there has a way to save your bits and pieces off to the side (branches, forks, shelvesets, etc.) while they are not complete ideas.  Your feature should be committed to the trunk in a single piece.
• There are automated tests around as much of it as possible (i.e. all of it).
• We can show it to the customer and they can understand it easily.

We write software.  If our automated builds/test are broken, then we are no longer writing software, we are writing bugs.  Therefore a properly functioning, successful (green) build is a priority.  We regularly monitor our builds and fix them.  Our software is tested automatically;  we do not accept broken software.