- Don't confuse development with typing. Encourage ... nay, demand! that your "developers" design. You'll find that the best ones will thank you for it.
- Give your developers tasks, then listen to them when they say "X weeks". Theoretically, they are your experts. If business needs conflict, discuss - never dictate. They'll deliver, but it will destroy your productivity.
- Make sure that your developers understand where they fit and why they personally are important. A little ego-stroking goes a long, long way.
- Make sure that the people developing requirements actually talk to the developers to make sure that requirements are sane BEFORE PROMISING THEM TO THE CLIENT. If you can't do that, at least make sure that the delivery dates are based on developer estimates. I once worked at a place where we had 27 days from receiving requirements we had no input in to putting it into production. Not good.
- Have a dedicated testing team that is independent of the developers and management.
- Make sure that there is at least 2 testers for every 3 developers.
- Analysts analyze, developers develop, managers manage, but only testers can approve code for production.
- Every time a requirement is decided on, a tester has to sign off. Otherwise, the requirement may not be verifiable.
- A tester has to be invited in every design and code review.
- Oh - require that all designs and all code be peer-reviewed. I personally think XP is overkill, but reviews are critical. The most productive place I've ever worked mandated these, and I loved it. (That 27 days place? The CTO thought design was something we were supposed to do on our own time.)
There's more, but it's been said by others.
We are the carpenters and bricklayers of the Information Age.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.