1.
Code Review tool for
personal effectiveness and
waste analysis
Mikalai Alimenkou
@xpinjection
http://xpinjection.com

2.
Disclaimer
This talk is based on
personal experience

3.
Personal productivity?
Are you joking?

4.
Developers are
different…

5.
10x developers are NOT a myth

6.
Team Lead is responsible for the team

7.
Metrics help to understand reality

8.
Code Review practices in large team
• Local quality gates (coding standards in IDE, unit/integration
tests for module, smoke UI tests)
• Pre-commit quality gates (static code analysis, all
unit/integration tests)
• Internal team code review
• Cross-team code review
• Whole CI/CD pipeline after integration

9.
Typical wastes in software development

10.
How to map wastes?
• WAITING = MR waiting for review or merge
• TRANSPORTATION = MR review cycles
• MOTION = repeatable notes in several MRs for the same
team member
• INVENTORY = MR waiting for merge
• OVERPRODUCTION = MR that could not be merged

11.
Code Review tools

12.
Gerrit dashboard with all changes

13.
Metrics samples
• How many MRs developer produces during the week (task
decomposition)?
• How much time MR is waiting for merge (risks on merge,
deferred value)?
• How much time MR is hanging on review (focus lost, risks on
merge)?
• Does MR break quality gates? How often? (waste of time and
infrastructure capacity)
• What is MR size? (complex and less focused code review)

14.
Gerrit merge request view

15.
Metrics samples
• What is complexity of MR? (risks on merge, long review
cycle)
• How many people involved in code review? (waste of time)
• How many negative grades? (low quality of local review)
• Was MR reverted because of CI/CD issues? (waste of team
time and infrastructure capacity)
• Was MR locally tested with smoke UI tests? (deferred issues
on CI/CD pipeline)

16.
Gerrit merge request history

17.
Metrics samples
• How many revisions does MR have? (waste of time, delays)
• What issues does MR have on quality gates? (lack of local
tools configuration and local runs)
• Does MR have similar issues as in previous MRs? (waste of
time, lack of knowledge grow)
• How serious are issues found in MR? (lack of design,
repeated full development cycle)

18.
Task complexity is taken into account

19.
Developers have different focus factor

20.
Sample analysis in mixed team

21.
Summary
• Be careful with metrics
• Don’t publish them to avoid competition
• Link personal metrics with common team values and goals
• Some metrics could not be automated
• Look at trends, not single values
• Ask right questions
• Use coaching to promote improvements

22.
@xpinjection
http://xpinjection.com
mikalai.alimenkou@xpinjection.com