Alguns itens de 'boas práticas' que eu aplico nos servidores da minha equipe são bastante simples. Primeiro, antes de fazer o check-in, você deve sempre obter as atualizações mais recentes e executar uma compilação local, para garantir que ninguém mais tenha verificado nada em que o seu código colidir. Além disso, cuide de qualquer conflito de código na sua máquina local, não no servidor. Depois que seu código, com o código mais recente baixado, tiver sido confirmado para compilar e funcionar corretamente, você estará pronto para a próxima etapa. Execute todos os testes automatizados e inicie o check-in para garantir que eles ainda funcionem corretamente. Então, só para ter certeza, obtenha as últimas novamente.
Como administrador do TFS, é possível aplicar comentários em todos os check-ins. Eu recomendaria sempre colocar comentários de check-in para o seu trabalho, independentemente de ter sido aplicado ou não. Se você tiver a opção de fazê-lo, imponha-o. Certifique-se de que os comentários sejam, no mínimo, um resumo geral do que você alterou desde a última vez em que inseriu seu código. Dessa forma, se algo der errado, você poderá examinar os check-ins e ver, grosso modo, o que foi alterado nesse check-in. Isso torna a depuração de uma compilação quebrada muito mais fácil.
Além disso, se você tiver privilégios de administrador do TFS, imponha builds contínuos nos check-ins (para garantir que todos saibam imediatamente se o check-in deles quebra alguma coisa) e você pode configurar o servidor para realizar um check-in fechado ( se o código com check-in interrompe a compilação, o servidor a rejeita) ou você pode simplesmente criar um bug e atribuí-lo a quem quebrou a compilação.
Existem algumas outras opções que você pode ativar ou desativar para manter tudo bem em ordem ou sugerir ao administrador do TFS que mantenha as coisas boas e limpas ... mas elas são em grande parte preferência