I was just asked whether I had metrics to demonstrate our pairing practice benefits the business compared to waterfall.
In my business context, I can’t cost-justify the kind of measurement Jeff Sutherland illustrates in his paper demonstrating efficiencies with Scrum in a CMMI 5 organization. Someone needs to do the same thing for XP practices. We have raw data from our revision control and tracking if that will help.
What I have to say is subjective. As a VP, I want our work more innovative, our code more maintainable and our progress more predictable. Pairing supports these goals in the following ways:
Shared Ownership
A risk managed approach to IT encompasses the bus test – how deep a hole are you in if one or two key people we’re suddenly unavailable (as in hit by a bus). Aside from specifications, waterfall tries to solve this with comprehensive code reviews and standards guidelines. In my experience, these were good intentions that NEVER happened. The problem was they sat outside the inherent work of writing code and felt like overhead.
In pairing with switching, these goals are largely accomplished in real time. And rather than management pulling teeth, the team themselves champion it.
Visibility
In a waterfall process, accurately monitoring progress takes great amounts of non-value adding effort by someone with a high-level of development experience. In pairing, the pair is constantly discussing progress. A project manager (or scrum master in our case) in the room, is able to learn a lot osmotically without pulling developers off task.
Momentum
As a developer myself, I understand that even the most talented coder can get side tracked, distracted, bored or otherwise stall out. Pairing forces focus. In a culture of collaboration fostered by pairing, developers use each other to break through obstacles. Progress is much more predictable and developers produce more efficient and purposeful code.
New Hires and New Learning
Bringing new or junior members up to speed is a high overhead to a small team. Often, the best learning happens when two people of roughly the same skill work together. Sometimes someone with less experienced needs mentoring by someone with more. Pairing ensures each person has the opportunity to learn from everyone else. Carefully vetted, new hires on our team begin contributing within the first sprint.
I have complete confidence my team can bring in new technologies and languages. They’ve proven it to me with Ruby, WPF, and SQL Server OLAP/Analysis Services.
Creativity and Collegiality
The types of people who seek out a pairing environment are social, take initiative and want to engage in the big picture. These types of developers create a vital workplace and contribute more fully to product development. I’ve written several papers getting at the relationship between collaboration and innovation.
Pairing fosters friendships that extend beyond the workplace. Gallup has found a high correlation between worker engagement and whether they believe they “have a best friend at work.”
To Conclude
I admit these are all subjective observations. However, my day to day experience convinces me our team is much better for our pairing practice.
Since we began pairing, even the most senior of our developers has grown their technical and interpersonal skills. We have delivered predictably for our business on multiple streams of work in diverse, sometimes emerging technologies. I’m confident we can maintain our applications no matter which team member takes vacation.
Finally, not one of my team “clocks in”. They bring their whole selves to our work and our workplace. If a manager needs a chart to tell them why that matters, they shouldn’t have authority over people.
