Drupal community talks a lot about best practices. When I talk about best practices I mean code driven development, code reviews, SCRUM, automated tests… I immediately realised that introducing new ways of working is not going to be easy. So I figured, why not asking one of the smart people how to start. Amitai (CTO of Gizra) was very kind to have a call with me, explaining how The Gizra Way™ started and evolved.
One thing at a time
Making to many changes at once can backfire with a resistance. A new idea has to be sold to the team. It is impossible to expect that the whole team can just switch to a new way of working. Mastering one trade is better than struggling with many.
Having a testing period takes away the pressure. If it does not show any benefit after a week, then you can stop doing it, but you really have to try during that week.
Leading by example
Just giving instructions does not help. In most cases developers will not be able to see the benefit at first sight and it can even feel like a punishment. Even if you are not a developer, you can encourage the team to try their best during the trial.
Starting with a new best practice feels like procrastination. In the beginning I had hard time selling why we need to have every project on a GIT repository. Now we just say: no exceptions.
During our call with Amitai we discovered that reviewing code from other developers is the foundation of a great team. Code reviews can be as simple as asking colleagues what are they up to. So we started our trial week on code review. After one week I was able to see changes in how we communicate and help each other. In this spirit we ended up releasing two modules and switching developers to use same IDE.
What really resonated with me was the fact, that it doesn’t need to be perfect. As Amitai says: I am not a purist. Having one code review or one automated test is better than none at all.
I will leave you with this great presentation from Amitai in DrupalCon Austin 2014: