How long do your team members wait for async code review via the Pull Request (PR) process? An hour? 1 day? 1 week? I’ve seen teams where the average PR wait time was 4 weeks (!).
What do they do while they’re waiting?
Let’s save discussing the merits of applying the async PR—a process developed for the low-trust, low-bandwidth open-source world—to cohesive teams in the same organization for another time email. You’re likely using PRs at this moment in time, and you need to do something now.
In a typical org, after opening a PR for a work item, developers grab another work item and start working on it. If they compete these second work items before the original PRs, PRs begin to pile up as inventory.
Knowledge work has inventory too
You can spot inventory more easily in manufacturing, but it absolutely exists in software development too. Code awaiting review is an example of knowledge work inventory.
And just like in manufacturing, you’ve paid a cost for the inventory, but your customers haven’t derived any value—which means you haven’t derived any revenue.
Also just like in manufacturing, inventory piling up affects the product’s quality. Let me ask you this, if changes wait as PRs for two weeks, when reviewers finally get to the reviews and request feedback, how much working context of the changes do the authors have in their mind at that point? Is there now an inherent conflict? “Can’t you just get this through? I’ve been waiting for two weeks, and we have so many other changes we need to push through!”
Take action
You can’t solve a problem you can’t perceive, so today’s action item is to identify where in your organization you stockpile inventory. Think of the entire process from inception of an idea to release in production. Let me know what you find!
