TESTS

One of the first practices applied on my current project was Test Driven Development.
Programming in Ada95, we downloaded the AUnit open-source test framework.
Team-members actually began to enjoy testing, even though is was traditionally seen as boring activity.
In our common workspace, you can often hear: "Thank god these tests exist! They just detected a regression I added while changing the code ...".

PAIRING

Lets face it: Some people just dislike pair-programming and you can't force them.

We've never managed to practice systematic pairing. Too bad, because pair-programming is so efficient.

However, we've sort of transformed it into a "on-demand pairing" practice: "Hey, I've got this tough refactoring to do. Can someone come help me through this one?".

Its good to have a teammate ;o)

SYNCHRONIZE AND DELIVER AT LEAST ONCE A DAY

Instinctively, many developpers will keep their code checked-out overnight, or for several days.

That's another situation when it is good to share a common workspace. Indeed, you nearly always have a teammember to ask you: "You look satisfied with your tests results. Have you checked in and delivered your work?"

It's good to have a teammate ;o)

TEST-FIRST

This is a very tough discipline!

Even though experiencing it clearly reveals better designs, it is very difficult to make it a practice.

TESTING

When a bug is detected, there is nearly controllable force pushing team-members to hack a quick correction.

That's when you need a common workspace with a colleague asking THE question: "Have you started by adding a test revealing the bug?".

It's good to have a teammate ;o)

SUB-CONTRACTING, OUT-SOURCING, OFF-SHORING

We have been through painful sub-contracting experiences.
Even though everybody was fully competent and willing, everyone has suffered from contracts which enforced early decisions and following plans over responding to change.

HAVE A MENTOR

This personal practice is described in My Job Went To India [ChadFowler].

Fortunetly I have a coach in my job, and I seek a lot of advice from a very talented peer.

I also consider the authors of my favorite software engineering books as mentors. I track the lessons of Kent Beck, Robert Martin, Bertrand Meyer, Martin Fowler, Mary Poppendieck, Andy Hunt ...