Pair Programming Payoff

For a project that runs for, say six months or more, there should no extra development cost on account of pair programming. Period. If there is extra cost, it means pairing is not paying off for you. Pairing should pay off in the following difficult-to-measure ways:

1. Lesser rework during development on account of misunderstood/ill-defined requirements. These things surface quickly when pairs talk to each other.
2. Slight reduction in maintenance cost on account of clearer code. Because every line is now considered readable by at least two people. (more in case of pair rotation)
3. A better detail level design results when each pair acts as a sounding board for the other. Good design reduces cost of future change.
4. Faster/better process of bringing new team members up to speed.
5. Lesser impact of people taking vacations.
6. Lesser bugs in QA, UAT
7. More hours of focused work per day - however professional someone may be it is natural for concentration to wax and wane. Pairing almost always helps here. 
8. Unlike the case of no-pairing, there is no separate code-review activity required
   

How do you figure if there is extra cost? Estimate both ways. The total 'release-lifecycle effort' for the case of pairing should not exceed that of no-pairing. Individual stories may indicate greater effort but that is okay. It is very difficult to do controlled experiments to nail this down. There are some studies but your mileage may vary.

A word of caution when estimating for such comparisons. Remember that on all real projects, actuals mostly exceed estimates. Some of the difference is borne by the client (change control etc) and the rest by the vendor (unpaid overtime etc). You need to have a realistic idea of effort overrun for the case of no-pairing to be able to compare it with the overrun for the case of pairing.

If pairing is resulting in net higher development cost on a long running project, then it simply means (to paraphrase Kent Beck) that the client is getting XP'd on :)

Label activities, not people

Ideally, an XP team consists of all talented and experienced people. Every person is assumed to have good communication skills, technical skills, ability to analyze and synthesize, understanding of business drivers, ability to make trade-offs based on business constraints and the ability to work as part of a team. Indeed, there probably are thousands of people who qualify on all these counts scattered around the world. But IT is a pervasive beast. It touches almost every aspect of modern business. IT is also labor intensive. The demand for really good people outstrips supply by a factor of hundred if not more.  IT vendors who practice XP are therefore forced to move away from the ideal of more or less homogeneous poly-skilled teams.

Instead, we hire people who have a subset of the above skills and assign them to specific roles in a team. So we have roles like developer, analyst, QA, manager, UX dude/dudette etc. It is essential to recognize that this arrangement is a departure from the ideal - a compromise driven by market reality. How we look at roles depends on our model of the ideal world. If you agree with the XP ideal, then roles are labels attached to the activities on a project. e.g. performance tuning activity needs developer role, activity of scope negotiation needs manager role.

But all too often, we lose sight of the ideal and think of roles as labels attached to the people on a project. e.g. person A is a manager, anything she says outside her labeled area of competency should be taken with a pinch of salt, person B is a developer, anything she says outside her labeled area of competency should be taken with a pinch of salt, and so on. We forget that the labeled area of competency is merely a mutual agreement at the time of recruitment. We end up discounting the credibility of people outside their labeled domains.

This kind of thinking also magnifies capacity constraints in a team. Say we have 4 people with label QA and 12 people with label developer on a team. What happens when stories start piling up in QA? We are less likely to see if some developers can add temporary capacity to QA. Oh no, that would never do. Developers can't test. They are not wired to test. Mass stereotyping sets in.

Soon people start buying into their labels. Developers refuse to test. If you can communicate well, you are suspect as a developer. Managers shy away from writing code, or (shudder) gaining even basic user level technical competence. They go about saying "I can't handle technology", as if it were a feather in their cap. We become more and more entrenched in the silos created by our labels. Truly ploy-skilled people get disheartened in the process. A person with a label of analyst may have a great aptitude for domain modeling. But her inputs may be sidelined by developers. After a while she either starts believing in her artificial limitations or she starts looking for another job where her skills are more broadly appreciated.

It is no good to call everyone consultant and then use a different labeling scheme when it comes to staffing projects. To the extent of their skills, people should get to play multiple roles within a single project. Oh, that complicates staffing. So? Should the tail wag the dog?

Organized religion came about partly as a result of our need for identity and self-worth. It is probably reassuring to say "I belong to this group" and then move on to thinking "My group is better than the other group". We may have outgrown traditional organized religion but we seem to be falling for newer versions.

Fail fast

When failure is a possibility, design to fail fast rather than slowly. Doing so reduces the cost/impact of failure. What is equally important, failing fast makes further attempts feasible. Learning from previous failures makes future attempts more likely to succeed. This principle is widely applicable in software development:

1. Methodologies that have fail fast mechanisms baked in are more likely to generate greater ROI. More on this later.
   
2. Guerilla SOA is arguably a fail fast take on big up-front SOA.
3. Code that is written to fail fast is likely to be more reliable in production.
4. Small, frequent check-ins are likely to cause less overall rework than big, infrequent ones.
   

Verification: When and How?

But how do you decide at any given checkpoint if we have a success or failure at hand? The quality of verification is crucial. Verification by peer review, while valuable, is prone to oversight. The proof of the pudding is in the eating. The more times you get to eat the better. The analog of eating here is testing functionality. A truly iterative process of software development where functionality gets tested iteratively is likely to achieve better ROI (everything else remaining constant).

Okay, so no one uses waterfall anymore. But we still have projects where big up-front analysis and design are the norm and continuous integration means weekly build. In such cases, we only have limited verification (peer reviews of requirements, design and code) till the very end. Failures (if any) are slow and horrible.

Incremental agile is what almost all XP and Scrum teams follow. They run through the stories for a release doing just enough/just in time analysis, design, coding per story. The boundaries between design and code are often blurred but that is not material to this illustration. Truer verification now becomes possible at the end of every story (QA/customer testing/sign-off). However, each story still gets only attempt. Any changes (learnings?) after that go back into the backlog to be prioritized and taken up with everything else.

But as Jeff Patton points out, it is possible to view each story as a series of progressive enhancements:

1. Necessity - core functionality (e.g. user registration)
2. Safety - validations etc. (e.g. confirm via email, add a captcha)
   
3. Flexibility (e.g. support openID)
4. Luxury (e.g. add ajaxy feedback on available userids, password strength)
   

Yeah the example is a bit contrived (openID would mostly be another story even in incremental mode) but you get my drift. We can now design a release plan that allows the team to iterate on a story, progressively enhancing it. The story sponsor reviews (tests) each story multiple times. Failures (if any) are faster and cheaper. The team learns better. I like this line from a Werner Vogels interview:

With a new radical service, you try to go into prototype mode pretty quickly, and then you start iterating on that until you feel that you understand your business problem.

Stories in regular business applications may not qualify as radically new but very often the team is new to the application in question. "You only understand it when you do it" is a much under-appreciated truth of all knowledge activity (if not all activity).

Expected cost/time

It may be argued that for a given chunk of functionality, iterating increases overall cost/time as compared to doing it in one go. This is only true when the risk of failure is zero. For situations of non-zero risk, the expected cost/time can often be lower with an iterative approach. The table below shows this for a hypothetical but realistic risk profile where risk decreases as learning increases. Your mileage will vary depending on the risk profile of your team and functionality.

Failure is not an option

Sometimes you get to hear sponsors saying they don't care about downside risk because failure is not an option. Some of these projects run into a death march followed by a blow out followed by movement of key people. Then a new team and a new IT partner get to do it all over again.