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 on the long run. Instead of using make, 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 developer" 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 they decided to work in pairs. This way the unwilling_to_change_developers had the chance to see how this can be done and experience the benefits of this approach.
Mark 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 during the conference.
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 reword the people from inside your team that already adopted (the early adopters)
- organize dojo's inside 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 though 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 make their (daily) job done. They are early adopters for their weekend project.
