How mature is the product that the team is working on?
I think as a product (or core dependency) becomes more mature code reviews are immensely valuable. It also seems to become an issue when new members of the team are still getting their bearings. When a new member joins my team I generally book time explicitly for reviewing not only code but the development process that they follow. This helps suss out any issues they may have with environment, workflow , etc.
The product is mature enough to warrant all of those things, and when new members of the team are on-boarded, time is certainly carved out for code orientation. However, being forced to work on a story from beginning to end with a team member who knows how to pair well and knows the code base well is even more valuable in the end. Pairing is absolutely the best way to share knowledge, as it is necessary for the pair to be successful.
Comments
Good points in there. It might be that our personalities on our small team lend well to pairing and it might not scale out as we grow the team.
I would say though that it feels like we have even better visibility into new discoveries/successes/failures.
Every morning, we have a standard standup and afterwards we talk about anything anyone jotted down on the whiteboard from the previous day.
Today, it was huddling around some code for 10 minutes that refactored the way we setup some of our specs.
How mature is the product that the team is working on?
I think as a product (or core dependency) becomes more mature code reviews are immensely valuable. It also seems to become an issue when new members of the team are still getting their bearings. When a new member joins my team I generally book time explicitly for reviewing not only code but the development process that they follow. This helps suss out any issues they may have with environment, workflow , etc.
The product is mature enough to warrant all of those things, and when new members of the team are on-boarded, time is certainly carved out for code orientation. However, being forced to work on a story from beginning to end with a team member who knows how to pair well and knows the code base well is even more valuable in the end. Pairing is absolutely the best way to share knowledge, as it is necessary for the pair to be successful.
Maybe there's a list of preconditions which help improve a team's chances for successful adoption?
I can imagine teams where pairing unleashes creativity, resourcefulness; and teams where it'd be intolerable.