Feature Partner

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 ensure that your code gets reviewed by someone with enough context .

Tasks and Assignments

In some teams, coding is primarily done by individuals. The timely, relevant, and actionable feedback that makes for a useful code review requires context, 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.

Another value of Code Review is knowledge sharing, but a pre-merge core review is not the time for revisiting the details of every decision.

In the interest of getting prompt feedback, you might consider asking the team at large for comments 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,

You might consider having a designated reviewer — a manager or 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 designated-reviewer approach:

• might become a bottleneck either for reviews or for design discussions.
• 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.
• creates a dynamic that removes some ownership from the development team.

Pair Programming might provide an opportunity to have a reviewer with all the context, but:

• Not all teams do pair programming well
• Since a pair is co-creating code, some changes might benefit from the perspective of a non-author.

Having someone familiar with the context but not too close to the implementation available for feedback can lead to valuable insights, as Adam Alter says in Anatomy of a Breakthrough {Alter, 2024 #278933}:

The more you consult with nonredundant outsiders, the more diverse your inputs, and the more likely you are to move beyond stubborn personal defaults.

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 input.

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 involved in all key design discussions and responsible for providing prompt feedback**


Defining the partner relationship explicitly clarifies that time spent reviewing and designing code in progress — even if you are not coding — 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.

Any team, an agile team, in particular, needs to be aligned on goals rather than individual achievements. As Gil Broza says in The Human Side of Agile {Broza, 2012 #254478}:

First, the team truly needs to be a team. Everyone needs a common goal and interdependent commitments so that everyone has the same long-term view and the feeling of being together in the same boat. Individual ownership, obligations, and objectives take away from being a team.

Feature Partners can take many forms, including:

• Developers participating in Pair Programming (being mindful about switching pairs and groupthink)
• Individual developers working on 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 committed to being a sounding board and resource can minimize development delays. Even having two people who commit to discussing and reviewing each other’s code will be valuable.

Example

Implementing feature partners is as simple as acknowledging that at least two people will be associated with every backlog item or feature. You can determine this:

• During Sprint Planning
• When a backlog item is moved to In Progress

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. However, a Code Review might not be the best time for these conversations.

If you use Pair Programming, consider whether the co-creation nature of a pair could take away some of the “external perspective” value of a review and if that element will be problematic.

If the larger organization doesn’t prioritize team goals over individual delivery, having Feature Partners can get pushback.

Next Steps

• Feature Partner depends on there being a Team Focus; a commitment to working on features rather than tasks.