Mixing Up the Pairs and Collective Code Ownership
During my current team’s daily Scrums we’ll finish up by organizing our day. It is usually pretty obvious what stories we need to be working on based on the state of the Scrum board, but who should be working on them is not always so clear. During the lifetime of a story (which most often is multiple days) I will start to get uncomfortable if it has been worked on by the same pair. As the Team Lead I’ll raise the question, “should we mix up the pairs?”
As a team we are striving to attain collective code ownership. We are close, but not quite there. In order to get there as fast as possible, I feel that switching pairs often is one of the answers, but in the early stages this can be difficult and exhausting.
The previous team I led did reach a level of collective code ownership. We committed to switching pairs at least twice a day, and facilitated this by introducing a mid-day stand-up to reorganize the team. We would also use this time to discuss the progress of our current stories, before getting back at it. Our experience at the time revealed the following pros and cons.
- lots of time spent “ramping up” a new pairing partner after joining a story in progress
- developers could become frustrated having to give detailed explanations to new pairs multiple times per day
- it was very draining for developers to have to switch contexts so often
- better design resulted from multiple developers being involved in the story
- developers were seeing all areas of the code
- the team was suppressing the creation of “experts” for certain areas of the system. Everyone was an expert – our truck number was rising.
- daily Scrums were becoming more useful since everyone understood the stories being discussed. No one had that glazed look on their face waiting for their “turn to report in”
- our velocity started to increase
The process was not easy, but as we pushed forward we found that the time to get brought up-to-speed gradually got shorter. During the daily Scrums our discussions were now leading the developers to form the pairs on their own in a more natural fashion. And before we knew it they were switching pairs outside of our daily Scrums whenever they felt it made sense. That’s when I realized we had collective code ownership.
Like I mentioned earlier my new team is still working towards collective code ownership so I am trying to implement some of the steps my previous team took. The team is larger, and we are working with a bigger and more diverse code base, but I am confident that we will reach our goal.
I am interested to hear about others people’s experiences in this area. What measures did your team make to maximize your truck number? When do you think it makes sense to switch pairs?