Pair programming is a controversial topic. The majority of the projects I've been involved with always have at least one skeptic on the team. The skeptics always cause me to take another look at the practice and see if the specific project provides a new point of view to the discussion.
On my last project I learned that large gaps in talent can turn a teammate into nothing more than a spellchecker. This generally seemed to happen when one member of a pair was significantly more skilled than the other. In the case of an experience gap the more skilled pair can slow down and mentor the junior pair member; however, sometimes a story needs to be completed as soon as possible. In the cases where time is very valuable it seems to make sense to rotate in a more experienced teammate or to split the pair until a more experienced teammate can join the pair.
While I generally prefer pairing, if a teammate is providing nothing more than spelling suggestions it is probably not the best use of his time. Furthermore, when an experienced teammate is required to slow down to explain things, then the pair is not closing the card as quickly as possible.
Can't you, shouldn't you, consider the time invested in educating your pair as paying down technical debt?
ReplyDeleteThe sooner and faster everyone's brought up to speed, the faster the team can go as a whole.
Pairing is absolutely about mentoring and knowledge sharing as much as it is about continuous code review.
ReplyDeleteBut it's naive to believe that there's never a situation where "a story needs to be completed as soon as possible"
In those situations, I think the observation applies.
Cheers, Jay
Sure, maybe the first time the story needs to be completed as soon as possible, but what about the next time, and the time after that?
ReplyDeleteMaybe the situation is as it is because the spellchecker isn't up to speed yet.
I'm not saying that the "finish the damned card already" scenario never happens, but at some point it becomes a symptom of technical (educational?) debt. If we apply the five whys principle:
1. Why should I break this pair?
Because I the story needs to be completed as soon as possible.
2. Why does it need to be completed as soon as possible?
Because we're slipping on our estimates
3. Why's that?
Because some of us aren't up to speed.
4. Why's that?
Because the people who are up to speed are letting the obligation to accelerate the people around them slide.
5. Why's that?
Because they're breaking pairs with 'spellcheckers' in the face of deadline pressure?
Obviously, that's not how the five why chain will run in your case, but I do think that we should be very careful of falling into that trap.
I think point 2 that Piers makes is important - "Why does it need to be completed as soon as possible?". He suggests "Because we're slipping on our estimates". I think the estimates (or at least the expectation that the estimates will be accurate) should reflect the fact that less experienced developers have joined the team. It's often not sufficiently recognised by managers that bringing extra developers onto a team (whether they are experienced or not) will tend to slow the team down for a while as domain knowledge is transferred. I think it may be a warning sign if deadlines start driving one's behaviour. It could to be time to discuss reducing the scope or moving the deadline.
ReplyDeleteOut of interest, in your scenario what do the 'spellcheckers' do with their time...?
Time crunches aren't limited to bad choices. The last iteration of a release isn't always the best time to be mentoring. Yes, you will pick up some knowledge sharing debt; however, slipping a date can effect other teams (QA, production support) so sometimes picking up that debt is the more effective solution.
ReplyDeleteAnother situation we faced on the previous project was undertaking large refactorings. Mentoring isn't the top priority when you are fixing something that the entire depends on, especially when your team size includes 16 devs. Following the completion, there should always be a dev discussion concerning the solution. In this discussion the mentoring can occur. It's less effective for the junior team member's learning experience; however, slowing down a major refactoring is less effective for the entire team.
What can a spellchecker do? Hopefully the team member isn't a spellchecker for all tasks. Ideally the spellchecker rotates on to a card where they can provide value. If that option isn't available, then you find the next best use of their time. Perhaps fixing bugs or even starting a new card by themselves. Hopefully the spellchecker is a contributing team member overall, just not up to speed on a specific issue.
Nice read.
ReplyDeleteWe do pair-programming a lot on our team. Nevertheless, if one of the developers had to fix an urgent bug and did not have time to bring somebody else up to speed on some specific technology involved, he would work on it solo for a few hours, and then pair again afterwards.