In November, the Escalation team brought down our average code review time for our tickets from around 6 days to around 3:

...

To address these concerns, the team talked to other teams in Lahore about their processes, then came up with this this list of guidelines, which I’ll summarize here:

...

• Give team ownership: One of the first things we did was hand over our daily standup meeting to the remote team to facilitate. While a small change in our procedure, it made the remote team start to feel that they were as empowered as the team in Cambridge. After managing the stand-up meeting, team felt confident enough to take ownership of improving code review. One of the most important insights to come out of all this is that the team didn’t feel empowered before, either about the codebase or our internal processes.

• Code Review is as important as coding: we had to accept that code review is as important as writing code. If you do not review, the change will not be merged and ultimately it makes no sense to write some code if it’s never deployed.

• Feel confident: You (team) are owner of your code, feel confident reviewing your own code.

• Performance Review Meeting: With our newfound confidence and sense of empowerment, we started looking internally about our own performance. How much work we were actually doing? How many issues were we triaging? How many issues are we fixing? Closing without a fix? The team decided to start capturing these metrics on a biweekly basis.

• Embrace positive change

• Be communicative internally

...

The main benefit from the project wasn’t just the improvement in code review; it was the feeling of ownership and empowerment that the team felt in taking on the project in the manner that we did. Now, we’d love to hear your thoughts. Do you have suggestions for us? Did we have insights that your team might be able to use? Anything we overlooked or should change?

Thanks for reading!

Attribution

Original Author: Awais Jibran (Deactivated)

Edited by: Adam Palay (Deactivated)