Making devs do code reviews and unit tests

The starting point of the discussions was that we cannot make somebody do something, at least not in the long run. Instead of thinking at making somebody do something, we should focus on creating an environment that enables people to achieve what we want (in our case, do code reviews and write unit tests).

One story that was shared was about some "old-style developers" that didn't want to write unit tests before writing the code (they didn't see that necessary). In order to help them change their attitude the team decided to work in pairs. This way the unwilling_to_change_developers had the chance to see how this could be done and experience the benefits of this approach.

Mark Coleman shared some ideas from Fearless Change - http://www.bookdepository.co.uk/Fearless-Steve-Chandler/9781934759158, a book on change management that he happened to be reading at the time.

Here are some other ideas that were discussed:

• would you like to spend your time fixing build bugs, or would like to spend 2 hours with somebody to review the code
• inspire and reward the people from your team that already adopted the new practices (the early adopters)
• organize dojos within your company with the early adopters to spread the news
• pay attention to the "saboteurs" from within your team (even if the person is not intentionally sabotaging)
• state the problem, and not the solution you thought of. Tell your team what you want them to achieve, and not the solution you already thought of. This way the adoption of a new method or approach will be organic and people will have a better view of why this change is needed.
• software people are not early adopters regarding things that get their (daily) job done. They are early adopters for their weekend project.