i'm going to be very frank here.

Real teamwork is a consensus.

That's why small teams work best because everyone knows you can't get a consensus with any thing more than about 5 people.

At times, you'll have the sueaky wheel... but they sueaky for a reason. Listen to what they have to say, apply their concerns to what you're doing. Get them on board. No, don't strong arm them... or muscle them into doing it... but really get at the heart of their issue.

So teamwork is about consensus and therefore you're only as good as your two weakest links. Face it, if there's one weak link, you can train them up, pair them with someone more knowledgable etc. If there's 2, then that's probably about half your team and you're done at that point because you can't have half your team 'in training'.

So what Am i trying to say here?

Well, if you got a couple engineers who absolutely doesn't get polymorphism and inheritance... you can't use that stuff. Why? because they won't understand it then there will be frustration.

If you got 2 or more engineers who just don't get automated unit testing. Then you can't do it!

2 or more team members who don't get user stories... don't do them.

2 or more engineers who don't understand coding standards or write cleanly... you probably can't do "collective code ownership", your better off doing class ownership model.

Anyhow, you get my drift i hope.

A wiser man than me said "I get the idea of best practices, but for right now let's just use 'good enough' practices and get on with it"