There is a small team of 4 developers. These guys are very different from each other.
John is experienced and worked for more than 15 years with the company in different roles. His mantra is “never change a working approach”. He preservers the status quo.
William has the same level of experience in the company but has developed a love for the latest “best practices”. He is always on the look out how to improve things.
Mary is with the company just for a few years and then fresh from University. Some of the “old stuff” she is dealing with is hurting her sense of “doing it right” albeit she acknowledges it works. Refactoring would make maintenance and support easier but would have no visible benefit for the end user.
Alan joins the team and it is his first job. He likes the solid and calm approach from John, the energy from William who always seem to find a way to make stuff better for the customer, and the quick thinking Mary who knows tech stuff in and out.
The team leader struggles at times to get them working together effectively. 2 pairs emerge initially, William and Mary driving change with John and Alan asking, isn’t it working fine? Both have very valid points and the team leader would love to get more synergy going and not risking confrontation between the pairs.
Several approaches come to his mind and he settles on breaking the pairs up by switching the 2 younger members around. To get the learning going he asks the pairs to review their work. One of the older guys, John, has a problem with that as he feels Mary being “too cocky” about the old and well proven way he does things.
The team leader remembers a story he heard once how an airline handled a similar challenge. He takes John and William for a walk and explains to them the idea. He asks them to purposely insert some mistakes in their code. That way there is no loss of face, even if the younger guys find things that were made accidentally. He also tells the younger guys so they know there is no conflict between reviewing code and not making friends with team mates.
This approach can be refined to address the different ways of coding, create appreciation of a new way of doing things as well as proven methods.