Code Review Columns in Kanban

This scenario is very specific for my team, and may or may not work for yours.

Like most of the cool kids today, ours is a cross functional team, no QAs who do “testing”, and the team has a pull-request based workflow of code integration, with reviews being done by any member of the team.

Recently our team moved from Scrum to Kanban, and when the question of the specific columns on the Kanban board came up, there was a a preference to have a “code-review” column that developers would push to once they were code-complete with their task, so that they could move on to the next.

Certainly, there will be WIP limits to ensure that the column does not get too backed up.

Nevertheless, I think this is a bad idea. There are philosophical arguments against the practice, and also from a practical perspective, it is no better than having a single “In Development” column. Hear me out.

Philosophically, code that is not merged into master and waiting for review in technically “In development”. As such, the ownership of the unmerged code as well as the story card is still with the developer who wrote the code.

Pushing it to a buffer column so that we don’t affect the WIP limits of the development column seems like a good idea at the start, but I believe it makes the developers relinquish responsibility by throwing the code over to the reviewers’ metaphorical wall.

My question would be, why?

A good argument I have heard is that it improves the visibility of cards “blocked” by review. My answer to that would be that if you were to have a suitable WIP limit on your “In Development” column, you would still have the same visibility, because you will hit your WIP limit often in such a case.

Pushing cards to a buffer column of sorts, merely is a feel-good process for developers who would like to think they made progress, but really haven’t. That story card is still in development.

Call it as such.

Even with an “In-Review” column…

What happens if you were to find something during the review that might require major changes by the original author? Would you keep developing on the card while it is still “In-Review”? That affects your the WIP limit in the “In-Review” column, because this task occupies a place there, even though it is not being reviewed, is being worked on.

You could move the cards backwards, but then be aware that this has it’s own set of problems. You could maybe also increase the WIP limit on the review column, and make it such that card can be developed on while still being in the column, but that means that there is an opportunity to pile up more cards in the review columns which could delay the integration of code.

Another philosophical argument against this practice is that Kanban is a pull-based workflow, not a push-based one. There is no “review-team” sitting around to pull work from the “in-development” column, so why is this a column on your board?

My point is that In Review is In Development. You don’t need two columns for that, keep things simple.

I would suggest having a single In Development column with a WIP limit of n+2, where n is the team size. That would mean that not more than 2 cards are in review at a time, and would also enable a developer who might have worked on two cards (and have two cards in review), some slack time. This slack time could then be used to improve things on the project that won’t require reviews, such as improving CI/CD, paying of tech-debt, documentation or researching a new feature. Slack time is good, in a team, and must be seen as a positive thing to have from time to time.

Albeit, things might be different for you and your team. As is always in software development, YMMV. I am still in the process of going through this transformation at work, so I might learn a few new things along the way, and update this article as such when it happens.