I find that best practices are a bit like design patterns. They are emergent in that a successful team will undoubtedly be using many of them. However, they are not something you can prescribe directly. Just like you can't use design patterns like ordering off of a menu (I'll have a bowl full of factories, a side order of singletons and a large bridge, please), you can't pick a handful of "best practices", sew them together and expect that, in itself, to make you successful.

Being aware of best practices gives you the ability to move in that direction when you see opportunities. It is a mistake, in my opinion, to try to force the opportunities by dictating best practices (something that is done far too often in software process engineering). The best practice you choose depends a lot on the situation and the people involved.

Having said that, I have all too often been in situations where I'm thinking, "I know how to be successful if we could do X, Y, and Z. I have absolutely no idea how to be successful doing the things we are doing now." It's tempting to try and force people's hands, but I have never seen it work. It's usually much better to search for an A, B, and C that will work instead. Not always easy, but it's I suppose it is how you demonstrate that you deserve the big bucks ;-)