Recently I conducted a code review for one of our customers. They already are using A3 reports internally as problem solving and report tool. I really like A3, so I thought why not try if a code review fits in a A3 report.
A lot of code reviews I come across are wordy documents basically copy-pasting the reports of what tools like sonar provide to you for free. In all the teams I know or coached such tools are already available so there is really now need anymore to put that kind of information in a code review report (providing a link should be sufficient).
I think a code review report should be concise, clear and with concrete actions on how to improve. Since these are also characteristics of an A3, let’s see how they fit together.
A typical A3 consists of the following steps1:
1. Identify problem
3. Root cause analysis
4. Propose counter measures
5. Develop target state
6. Create implementation plan
7. Develop follow-up plan with predicted outcome
Since A3 is a problem solving tool it doesn’t map 1-to-1 to a code review. The nature of a code review is different then a problem solving process (the code review could be input for a real A3 though).
Some parts can be used, so I mapped this to a code review as follows:
This will give you the report in a nice and concise format.
Then starts the next and probably important part of the code review: The follow up. This means discuss the review with your client and the team members. Come up with an implementation and follow-up plan together with the team.
Happy code reviewing!