malvasia bianca

One of the most interesting entries for me on the Agile Toolkit podcast is the one on promiscuous pairing and the least qualified implementor. What the interviewee proposes is that, when starting on a card, the person who knows the least about it should work on the card, pairing with somebody who knows more about the topic at hand. The group should change pairs every two hours; each time, the expert works on a different card, while the former novice takes up the expert role (since he now knows more about the task at hand), and pairs with the person in the group who now knows the least about the task. So there’s no one owner for the card: instead, different people in the group work on it for four hours, in the novice role for two hours and in the expert role for two hours.

He has data to back this up, too. His team has measured its velocity using different pairing strategies and lengths, and, for example, has a significantly higher velocity when rotating pairs every two hours than when using a longer pairing duration. Hearing about these was a warning sign for me: until a few months ago, points in our group corresponded to actual time spent rather than a given story difficulty, which meant that it was impossible to measure velocity improvements (since actual time spent didn’t change). To be honest, right now it’s not clear to me how stable our point estimates are, but at least it’s conceivable that we could measure velocity differences, which makes the scientist in me happy.

Anyways, I mentioned it to my team, but got a lukewarm response; their attitude was that if I felt strongly about this, then we could give it a try, but they didn’t seem too excited. And I didn’t feel too strongly about it, so we let it slide. It did leave one idea, though: before, at each weekly planning session, we’d divided up the cards so every card had an owner. But this podcast suggested that doing so wasn’t essential. What we ended up trying was having each person pick one card that they owned, but leaving the extra cards unowned; then, when somebody finished a card, they could pick a card from the unowned stack. (Or just pair with somebody else for a while, of course.) Cards can also change owners; that’s somewhat rare, but I did hand my card off to another team member yesterday, since I was busy yesterday afternoon (and will be in manager training next week; we’ll see what I learn there!) and he had just finished his card.

The first few weeks were a little chaotic, but our velocity has actually been rising since we made that change. To be sure, I have no reason to believe that this change was the trigger for the velocity improvement: we might have been in a period of abnormally low velocity before the change. That was a month where we were working on several new areas of the code, and we had underestimated the learning curve necessary; we made this change at around the time that we started to get a handle on the new areas. Still, at least it’s evidence that not dividing up all the cards at the start doesn’t hurt our velocity! And I personally prefer the new way of working: focus on a card, get it done, and take stock of the whole team’s status once you’re done with that card, to see how your efforts could best be directed at that point. This ‘limiting your focus’ idea shows up all over the place in agile work, to good effect.