- \n
![\"\"](\"http:\/\/blog.caplin.com\/wp-content\/uploads\/KanbanBoardWithNoQueuesInCodeReview-300x225.jpg\")
<\/a><\/dt>\n- The team’s kanban board after we’d got rid of the queues, with no cards at all in the Code Review column.<\/dd>\n<\/dl>\n<\/div>\n
Introducing the Code Review process: a focus on \u2018just enough process\u2019<\/h2>\n
At the team meeting where we discussed a code review step we wanted to introduce \u2018just enough\u2019 process to make sure we would actually do it. We agreed to do the smallest thing that could work and to avoid being too ambitious or strict in how we defined code review. We came up with the following rules:<\/p>\n
- \n
- If the person worked alone they needed to ask someone else on the team to come to their machine and discuss the code.<\/li>\n
- The developer who needed the code review was responsible for pulling another person in to do it.<\/li>\n
- If two people paired on the task it didn\u2019t need a code review.<\/li>\n
- If the task didn’t need a code review then the developer responsible would say so at the daily stand up and if the team agreed, it could skip that step.<\/li>\n<\/ul>\n<\/div>\nWe also agreed to come back in a few weeks and review whether we thought the benefits of doing a code review were worth the costs by asking the team for examples of whether code review was ‘helpful or harmful’.<\/div>\n
What the board showed next: Good intentions were not enough<\/h2>\n
During the daily stand up meetings in the first week of working with the new process, the team reported many tasks as \u201cfinished development\u201d when they hadn\u2019t been code reviewed. We started moving those cards to the right of the “In Dev” column. Within a couple of days it was clear that we had a queue of index cards to the right of the “In Dev” column.<\/p>\n
We had a brief discussion on the queue of cards to the right of “In Dev” and we agreed that it was a sign that we weren’t doing code reviews in an effective way. We said we’d focus on doing code reviews and ‘unblock the queue’ that day.<\/p>\n
At the next day’s standup the queue was still there. This illustrates an important point; changing the way we work is hard and sometimes good intentions are not enough.<\/strong> At that day’s stand up meeting we had a deeper discussion about what was preventing us from doing it and identified two major issues.<\/p>\n
The first issue was a concern about interrupting other developers. We agreed that one solution was to do the reviews directly after stand-up, since the team had all been interrupted.<\/p>\n
A second issues was making it more obvious which cards were actively being worked on “In Dev” and which cards needed a code review. To be more explicit we created a column on the board between \u2018In Dev\u2019 and \u2018Waiting for Test\u2019 called \u2018Code Review\u2019.<\/p>\n
By the next day’s stand up the queue of cards in Code Review was gone and we haven’t seen a queue of work build up in code review since.<\/p>\n
Visualisation and productive conversations are key to process improvement<\/h2>\n
The kanban board showed us that our behaviour wasn\u2019t producing the goals we wanted. Seeing this and discussing it as a team helped us understand more about what was stopping us and allowed us to experiment and test new solutions, as well as providing ongoing feedback about whether the new process step was working effectively.<\/p>\n
What’s your experience implementing new process steps such as code review? Have you found visualising has been effective in reflecting how well your doing? Have you redesigned the way you visualise things in order to help you act more effectively? Let me know your views and experiences in the comments.<\/p>\n
This post originally appeared on Platformability: Insight from Caplin’s tech team<\/a><\/p>\n
Related articles<\/h6>\n
- The team’s kanban board after we’d got rid of the queues, with no cards at all in the Code Review column.<\/dd>\n<\/dl>\n<\/div>\n
![\"\"](\"http:\/\/blog.caplin.com\/wp-content\/uploads\/KanbanBoardWithNoQueuesInCodeReview.jpg\")
<\/a><\/dt>\n