Feature Partner
A Pattern to help complete Code Review
When Code Review is part of your development process you want to make it easier for developers to get timely and relevant feedback on their code changes. This pattern describes a structure you can apply to your team to make this easier.
Tasks and Assignments
In some teams, coding is primarily done by individuals. Timely, relevant, and actionable feedback makes for a useful code review, but that requires context. Getting this kind of feedback during a code review depends on several factors, in particular team members who:
Are available to give feedback close to the time the change is done
Have the context of the code to understand the requirements and design decisions.
Know the tech stack and the code base well enough to give reasonable feedback.
Knowledge sharing is another value of Code Review, but when discussing the rationale for a design transforms into revisiting the details of every decision, it can unnecessarily slow the development process.
You might consider that asking the team at large for feedback on any change would yield faster feedback, facilitate knowledge sharing, and allow for detached feedback, but:
Not all team members will have the requirements and design context and thus may only be able to provide superficial feedback.
Any individual might not prioritize giving feedback due to other commitments or because of a belief that someone else will get to it,
Since peer reviews present challenges, you might consider having a designated reviewer — someone with architectural oversight and a broad understanding of the project — review all changes. Having a senior person review all the code seems like it might be a good way to mitigate the risk related to lack of context and ensure uniformity of reviews, but a single reviewer also represents risks:
They might become a bottleneck either for reviews or for design discussions.
They still might not know the rationales for some decisions that were discussed at length, and revisiting non-critical issues during a review is frustrating at best and time-wasting at worst.
A “senior reviewer” creates a dynamic that removes some ownership from the development team.
Ideally, you want feedback to be actionable and about improving the code, so it’s often better to have someone with a day-to-day implementation role give feedback.
Designated Partner and Shared Responsibility
Start each set of development tasks by ensuring that at least two people are committed to delivering a feature. Even if there is a single primary developer, the Feature Partner will be in all key design discussions and responsible for providing prompt feedback
Defining the partner relationship explicitly clarifies that time spent reviewing and designing code you are not delivering is a priority. This can also increase knowledge sharing on a deeper level.
Having a Feature Partner addresses three of the main challenges to good code review feedback:
Availability for review: The Feature Partner shares responsibility with the primary developer for delivering a set of tasks related to a feature.
Availability as a sounding board: The feature partner is jointly responsible for delivering a feature, so being available to discuss issues as they arise is part of the job.
Context: The Feature Partner is engaged in the feature’s planning and can be a good, high-bandwidth sounding board for questions during development.
Feature Partners can take many forms, including:
Developers participating in Pair Programming.
Individual developers working on different tasks related to the same story using the same tech stack, for example, two backend developers working on tasks related to a story.
Developers are working on different ends of an integration (backend and mobile, for example) to deliver the same feature.
Whatever the structure, the essential requirements are that the Feature Partners are:
Committed to working on a feature set.
Can provide appropriate code review feedback to their feature partner.
During a development iteration, feature partners will collaborate to:
Design code and interfaces.
Be a sounding board for ideas.
Meet with stakeholders to clarify questions about requirements and show work in progress.
Review each other’s code and unblock integration.
Using Feature Partners doesn’t preclude self-organization; the team can (and should) decide what partnering approach makes sense during planning and who the Feature Partners are. The important thing is that the organization acknowledges that having two (or more) people associated with a work item makes sense in terms of delivery and quality and that each development iteration starts with acknowledging this.
While it’s best that the Feature Partners actively develop code around a common theme, simply having someone who is committed to being a sounding board and resource can minimize development delays.
Cautions
Team members should have a role in identifying what they will be feature partners on— they should not be assigned top down.
Having Feature Partners doesn’t mean others can’t participate in discussions. Others on the team can also give valuable feedback. Explaining a design or code to someone, regardless of their knowledge, can be helpful. A person with a new perspective can often provide out-of-the-box insights, and explaining can help the developer identify gaps. A Code Reviewmight not, however, be the best time for these conversations,
Implementing Feature Partners
Implementing feature partners is as simple as acknowledging that there will be at least two people associated with every backlog item, and leaving interaction planning with a statement of who these people will be.
Next Steps
Feature Partner depends on there being a Team Focus; a commitment to working on features rather than tasks.
Notes/CItations
Black sheep: from Anatomy of a Breakthrough book: Value of outsider perspectives to shake things up