A member of any good scrum team utilises their scrum master to full effect, the moment a team member is blocked it is the responsibility of the scrum master to unblock them quickly and effectively so they can get back to contributing to the product. A good scrum master doesn’t mind the bad news that you are blocked, they thrive on it and do everything in their power to serve your needs and the team.
A well rounded scrum team is expected to respect ceremonies, consult the product owner, request assistance of the scrum master and collaborate with others. If a developer could choose where they spend their time, I would posit the majority want to be writing code. Give a developer a feature, a specification, and acceptance criteria and they will be heads down before you know it, eager to tackle the problem and challenge their creative side to deliver value and delight stakeholders.
You are ready to show off the code you have been crafting for days, hours or even minutes. It is time for a pull request to get the feedback, comments and approval of your peers. This is the step in the journey of a feature that I find disrupts flow the most and it makes sense when you think about it. As developers we are not interested in critiquing others work, we want to create and move on to creating more. Well now the code is blocked because our peers are busy with their own work and have little or no time to learn from your contribution, provide valuable insight and expand their knowledge.
I have seen pull requests sit untouched and ignored for days and weeks, the principal developer drops it off and moves on to the next task. Ready to take on the impending burden of context switching and believing they can deliver twice as much this way, unfortunately this just results in twice as many features blocked and incomplete. It is not the principal developer who is at fault, the team culture is in fact complicit in failing to respect the ceremony of code review. If a delivery driver leaves a package on your doorstep unattended you wouldn't consider that effectively delivered, so why not enlist the assistance of your scrum master to clear this blockage and expedite this step by chasing peers to help the team as a whole.
To be an effective developer contributing to the value of a product we must switch gears at code review and exercise our soft skills. Soft skills are underrated and under-utilised by many but collaboration and communication are the key to a successful and effective team. Communicating with our peers to seek feedback and comments to improve our code and learning to take criticism and advice positively. We don’t grow nearly as effectively as developers by working alone and never venturing out of our comfort zone.
So approach code review proactively by chasing peers for their contributions to drive through to delivery. Call on your scrum master to rally the troops. Eliminate context switching by focusing on seeing one task through to the end. Watch your delivery cycle flow, team morale grow and soft skills flourish. I have seen velocity double in my team by just this change of mindset alone, so give it a try with your team and let me know how respecting pull requests and expediting the code review works out for your team.