As I have said in numerous writings, managers must drive change with requirements and not dictate implementation details. Managers must find a way to empower and drive engineers to accomplish all of the tasks they need to do and not just the ones they consider to be fun. Many engineers consider any process to painful and bureaucratic. The best way I have discovered to overcome these issues is to delegate the definition and monitoring of development processes to engineers. Avoid having managers dictate and drive development processes.
My favorite way to delegate processes that affect all of engineering is to establish an engineering leadership team (ELT) to represent engineering. You must populate this team with people who are not process zealots. The members must be representative and respected. Make it clear they they will not do all the code reviews. Instead they will define the process and monitor it. Make sure you allocate real time for people to spend on this. Hold them accountable. Make sure they do not take forever to do it.
Once you have the ELT in place, it is your job to give them requirements and guidance. Often I will hand the team examples of what I have seen done elsewhere as a starting point. Then my management team will give them requirements. Here are some of the requirements I might set for code reviews:
- One process across engineering including QA
- Actions must be tracked
- Code reviews and addressing the resulting critical actions must occur before other internal and external people get exposed to the code
- Code reviews must be done in a timely manner
- A checklist with a minimum amount of what needs review must be developed to engender consistency and help junior member participate
- Code review results must be documented
- Need to have a fast track process for small things
Stay away from things that are not requirements. For example, I will not say what items must be checked or what timely means. That is for the ELT to decide.
I would give the team a week or two at maximum to define the process and roll it out. I would set goals with my management team about compliance and any transition needed. I would communicate how important this is to the whole team and ask them to be proud and not defensive.
Also be careful about tools. Many engineers would rather spend their time implementing a tool to facilitate a process like code reviews before your team decides what they want. Decide first and then if appropriate find or develop a tool to help.
Measure the results like how many features and/or bugs got code reviewed relative to the total, how many critical bugs were found, and how many total bugs were found.
Make this a priority and you and your team will reap benefits.
More later ..
