Technical team-building
I firmly believe that; if a team has a common view of how software is to be developed. The team can produce software a lot faster.
If not only for the fact that if the team shares a common view of how code is structured, in an object-oriented sense, then the communication cost between the team-members goes down. The individual team-member can figure out how the developer whom wrote a shared resource implemented specific features of that resource.
A common problem for this is that the team has different backgrounds and experiences. Which gives each individual developer a different opinion in how to develop software. Just take the example of the ever old Test-first or Test-last? Test-at-all?
Having technical team-building sessions could help close the gap between competences of different developers over a team.
Here are some ideas for holding technical team-building sessions
A technical team-building should be designed to give the developers of a team a common ground, or reference point, for how to design software.
You could have a mentor come in and have the developers go through exercises to learn specific techniques.
Give the team incentive for having all developers read a specific book. This book could then be used as a reference when having technical discussions. The goal being to establish a common set of principals for how to software is to be designed and developed. Communicate this goal frequently.
If you have a specific developer on the team who is into TDD and similar techniques, a suggestion would be not to have that developer introduce it. Instead have a mentor come in from the outside and demonstrate/teach the techniques. That way the developer becomes a natural source of knowledge for the team. Without risking that the team views the developer as know-it-all.