How to do lightweight code reviewsRecently 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 2. Research 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!