Priority of a Code Review in Kanban?



  • In a software development team, when should a developer perform a code review of another developer's task:

    • after completing their own task (another developer's task becomes blocked)

    • as soon as possible (inflicts context switching)

    • a policy is required (e.g. during a day, but also inflicts context switching)



  • It depends.

    It's important to realize that Kanban doesn't have anything to say about code reviews. It's simply a set of tools for visualizing and improving the workflow and flow of work through a workflow. There are a few key concepts - the Kanban board which provides a visualization of the workflow, work on the board, work-in-progress (WIP) limits, work item aging, cycle time, and throughput. These come together to show how work is or isn't flowing from one step to the next all the way through completion.

    If you are reaching WIP limits, those will be blocking things from either entering code review or entering the state following code review (such as a ready for test or testing state). The fact that WIP limits are being reached is an indicator to the team what needs to happen. If the WIP limit is in the next column, the team should focus their efforts on getting testing for work finished. If the code review column has its WIP limit reached, then the team should focus on reviewing work.

    If you aren't reaching WIP limits, you will need to consider work item aging and your service level expectations. The age of a work item is the amount of time that has elapsed between a work item starting and now. A service level expectation is an estimate of how long it will take for work to be done, often in time and a probability. When deciding what to do, you want to maximize the work that meets your service level expectations, so knowing which items are closest to exceeding those expectations should receive the first attention to move them through the workflow.

    Both of these options are based on the reduction of inventory, which is one of the seven wastes from lean. Work-in-progress is one form of inventory. Moving work through the workflow at the expected or desired rate (without compromising quality, of course, since defects and rework are also waste) is one focus of Kanban, and making any kind of bottlenecks or impediments highly visible is how this is achieved.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2