http://musingsof.raviwarrier.com

Visit me here! I am no longer writing stuff about work, but generally about things that come to my mind!

More than one can take...

This blog was supposed to be where I can vent out of frustrations about work and simultaneously give solutions or reasonings about the problems faced here; but I just can't take the crap anymore.
What is this world coming to? So much hatred and violence, where do these people get there fuel from?
I recently read about a nun being gang-raped in Orissa and then was made to parade around naked, while the facist saffronites yelled - "Bharat Mata Ki Jai". That last line really got me think on how perverted these people's sense of religion and patriotism. How can one even think of praising the "mother" when one is forcing himself upon a woman and shredding the bits all the dignity and respect that she carried with her. How can this glorify the motherland and womanhood?
The Bajrang Dal, that as far I can understand, follow Hanuman as their deity. When did they ever think that Hanuman would even think of raping women, humiliating them and killing innocents? 
My question is that don't these people even stop to think about what they are doing? Has the world gone so sour that all that remains of people's mind is curdled filth? Who gave them the idea that terrorizing, murdering, raping and ransacking houses of others is what the Hindu relgion is all about and that it OK for them to wear the saffron colored clothes and conduct such heineous crimes against humanity?
And if the entire country is questioning the morality of muslim extremists, why aren't we questioning the morality of hinduism and the so called saffron brigade? What makes these actions bad for one and acceptable for others?
Personally, I still believe that people in general are just a huge group of monkeys. It is the leaders, both spiritual and political, that have the responsibility of making these monkeys into humans. I know that not much can be expected from the class of politicians that we have, but I have thoroughly disappointed with the so-called "swamis", "sadhus", clerics and priests. What kind of understanding of the religion do they have and what are they imparting to these monkeys?
Today, I read the news that the Singh government is moving to ban the Bajrang Dal. My stand is that these guys should be caned first and then taught the meaning of Hindutva.

A Quality Partner's Role in a Senior Management Review

Yesterday, my boss and I had another difference of opinion. He had attended one of the delivery reviews (that's what sr. mgmt reviews are called where I currently work) and was shocked by the quality of the review. He was disappointed at the fact the senior manager did not ask questions pertaining to metrics, did not ask questions on how the plans were created, how effective was the tracking ,etc. He was even more so disappointed at me for not asking the questions myself.
Later after the review he called for a meeting to tell us what our role in the delivery review is supposed to be. He spoke about how the consultants (here we are called Quality Partners) should take charge of the review if the sr. management is not effectively conducting it and gave some wild anologies as usual.
I defended myself by saying that a delivery review is to be conducted by the delivery head and I ask questions that spin off from his where his questions are not rightly answered, or if he does not go deep into the topic. Most of the times, I list out the questions or concerns that I'd like him to look into and hand it over to him before the review to kind of point him in the right direction; and moreover, some senior guys don't like it if you butt into his review, no matter how good a job you do!
Also went on to tell him that all the questions that I have to ask of the project manager, I ask during "my" process reviews. He was not convinced. He said we had to be proactive and bring them on line.
If we are to do the delivery head's job today because he is incompetant, next we'd have to take on the engagement managers' work and then the project managers'. I asked him where do we stop. Instead of eradicting the root problem, we are just fueling it to get worse, because now we are slowly relying lesser and lesser on those seniors' ability to review the health of the project.
Since, he didn't have much to say on that (at least I think so), he said that I am still at fault here because I don't assist the delivery heads by sending them the fortnightly report which is a part of my job. I agreed that I don't send the report, but I do give them a heads up by listing out my concerns for them to address. But that, as per my boss, is not official and formal. So I had to agree again.
Now let's see, my boss, not only wants me to "proactively" do someone else's job, but continue doing what I do at my level. I think to myself, fine let's give this idea a try.
The boss has a talk with the delivery head in the morning today as he was going to conduct a review for another project. He tells the guy that it is my job to ask questions and that at times I will ask questions on his behalf and that he should not take if personally or offensively if I ever supersede him in directing the show.
What the delivery head hears is that it is my responsibility to ask questions in the review and that he can jump in whenever he wants to. He said to me that this is what my boss told him. I know!
Readers, the quality partner, process consultant, quality analyst, whatever he may be called is supposed to be the trusted advisor to the delivery. He is not the person you see standing in front in the meetings. He is the person standing behind the chair and giving information and advice to the person who is actually conducting the meeting. One thing my boss said is right - you must provide the delivery head with data. I completely agree. I also agree, if you live in the world of fear and need to cover your backs, then the communique between the two of you, needs to be official and formal; but nevertheless, whether formal or not, this information needs to reach him before he reviews.
To summarize, the role of the consultant in the senior management review is:

• Give information/status of the project before hand. You may supplement this with risks/issues that you foresee.
• Ask questions if the questions are not deep enough or if the answers are not satisfactory, basically assist in asking questions
  
• Correct him or the audience if their perception on some things is incorrect
• Make notes

But to take over the meeting is a no no! You are setting the wrong precedence and example. You are creating wrong perceptions as to who is in charge and who is affected by the problems of the project. Moreover, don't we always talk of management commitment; well if you are the one talking and questioning, how does one know that the senior management wants to get things done!
Think about it!

Using the Task Usage effectively

My organization recently adopted an Integrated Project Management (IPM) enterprise system. And more recently, underwent an upgrade where the scheduling (using Microsoft Project Schedule) and time entry modules were rolled out.

Naturally, due to the new change that enforced stricter rules for scheduling, the project managers were confounded with the way they were supposed to enter, schedule and allocate tasks in the project plan.

Two days back, a project manager tells me about his problem regarding the issue. His project, which he claimed is different than others (only if I got pennies everytime I heard that) gets a list of defects from the customer on a daily basis. His team is supposed to analyze, fix, verify, validate and deploy the fix for every defect they get. His problem is that the customer is "finicky" about this list and changes the priority of the defects midway, causing his team to drop the current task and take up a new one. His statement was that Microsoft Project was not helping him plan and track his team's activities efficiently and that he'd rather get back to the Excel based tracker that they used earlier.

I have rarely found a situation at work, when we can use the adage "Ignorance is bliss!" and in this project manager's case, the adage definitely did not fit.

Here're the premise of the scheduling he performed and different solutions I gave him:

Premise: Each defect is a single task item or a summary task depending on its complexity. Smaller/simpler defects are entered as a single task, while the more complex defects have sub-tasks such as "Analyze", "Fix", "Review", "Test" and "Check-in" as a milestone task.

If needed, various resources could be allocated to the individual sub-tasks or it could be the same resource. Individual task or sub-tasks are allocated planned effort (work) and the resources are leveled (over-allocations are resolved).

The customer wakes up in the middle of the day and asks that one particular defect be put on hold (defer it) or should be dropped (reject it) and work on any other defect.

Solution 1 - Scenario 1:

If the developer has worked on the defect and/or logged partial time for the amount he's worked for, then while entering time for that defect, he must mark the task as "done". Our IPM system updates the task as complete and logs the actual time against the task in the schedule. For the readers, who update the schedule manually, the process is the same - mark the task as complete and enter the effort (if you record "actual work" in the schedule) put in the task.

If the new defect is in the schedule, well, nothing needs to be done, otherwise, add the defect in the schedule and assign it to the developer (of course keeping the resource leveled).

Solution 1 - Scenario 2:

If work on the defect has not yet started, then simply one can either delete that task (not such a good idea as there would be no simple way of tracking of such a change later) or reduce the "work" for the task to 0hrs and mark the task as complete. That way it does not affect the overall project, except for its dependencies.

Solution 2:

This solution is a little tricky and will require good working knowledge of the Microsoft Project. If you are not confident about making changes to your master plan, make a copy and carry out the steps.

Project allows (as do many other scheduling softwares) the project manager to contour the task. Contour as the word suggests is the shape of the outline/surface of the object, in this case the object is a histogram of the work spent on the task each day. See the image below (not created in MS Project).

 

The top border (or the surface) of the histogram defines its contour, but I'm sure you figured it out already.

So, MS Project allows the following contours for each task:

1. Flat - Effort equally distributed
2. Back Loaded - Amount of effort gradually increases as the days go by
3. Front Loaded - Amount of effort gradually decreases as the days go by
4. Double Peak - The effort peaks twice during the life of the task
5. Early Peak - More effort is expended early on and then the amount stabilizes as the days go by
6. Late Peak - The effort is stable early on and then peaks towards the end of the task
7. Bell - This, if it is not wrong for me to call it so, can be termed as "Middle Peak"
8. Turtle - This is similar to the 'Bell' contour with the difference being that increase (during the early days) and decrease (during the later days) in effort is gradual and does not show peaks. Very similar to a turtle's back.

Selecting one of these contours will distribute the effort of the task as required in a ratio that Project calculates for you.

This can be done in the 'Task Usage' view (click on 'View' in the menu and then click on 'Task Usage'). Identify the task that you wish to work on, expand it (by clicking on the '+' sign next to it) to reveal the resource(s) assigned that task. Select and right-click on the resource(s) and select 'Assignment Information' option to see a dialog such as the one below.

 

It is on this dialog you will see the drop-down for Work Contour. Select one and proceed.

If you don't like the distribution the Project has set for the task, you are free to change the effort planned for each day in the pane on the right. In which case the indicator next to the resources will show icons like the following, indicating a custom contour.

 

So, if the task is put on hold for a definite duration, change the contour or task usage to reduce the effort spent on that task for those days to a minimum or zero.

This way, you don't lose track of the tasks nor do the resources have to enter time against (or work) on those tasks for the period of lull.

Should we SCRUM?

It is that time in the life of this industry when something new has passed the horizon and is approaching us at top speeds. Later in the last century, it was CMM, followed by CMMi in the early years of this one. This era of evolution sees the dawn of Agile practices.

Agile practices have been around for over a decade now. The industry just took it’s time shifting gears around it, slowly and steadily now advancing towards top gear.

We are all aware of what Agile practices in software development means, perhaps in its entirety as the authors of these practices intended it to be, or in some corrupt deviant phenomenon. We, as the flock of IT industry, believe this is the silver bullet that will release us from the clutches of software development hell. We also believe this one to be more silvery than its predecessors.

But remember this; this is exactly what the creators of this so-called weapon say it is not. There is not one piece of literature that states that Agile practices (in whatever form) are silver bullets that can magically kill all evils and make your life better.

SCRUM is one methodology that is based on the Agile philosophy. SCRUM, as I see it, is an excellent framework to improve overall project’s performance and provides good practices for Agile Project Management. It talks of well defined roles, limited number of artifacts (for project management and not as a part of the technical package of the project), and clear and concise rules on how each iteration needs to be executed.

It is not difficult to understand SCRUM. It would take less than hour to give a novice enough insight on SCRUM, to enable him/her to understand all its concepts. The difficult part, as with anything else in the world, is implementing it. And moreover, implementing it in services based IT companies.

While I evangelize SCRUM from the deepest corners of my heart, I have to but point out the fallacies of force-fitting SCRUM in places where it is not welcome.

Before we continue, let me lay down in front of you the scenario that I am considering while presenting the counter arguments of the implementing SCRUM in IT services industry.

“An organization, ABC Limited, is dedicated to providing IT solutions to its customers. The organization has many clients across the globe and is making/or has made its presence in the world of highly competitive market of providing services. It is a vision of this company to increase its size by another couple of thousand by then end of Financial Year 2009. It also aims to increase its revenues by 15% year over year for the next five years. The space that it operates in is also occupied by the top IT giants of India and hence has everyone fighting for the same piece of the pie.

“As with CMM and CMMi of yesteryears, the company now faces the demand from the western world to deliver their services in a SCRUM fashion. CxOs of client companies all across the globe have attended at least one conference in the past three years that showcased successful products that were developed in an SCRUM environment. Over the next couple of months, the CxO asks his/her executives to research and provide him/her with details of SCRUM framework and its benefits. The executives attended more seminars that evangelized SCRUM and came to a conclusive report that the organization must ask its vendor ABC Limited to adopt SCRUM.

“As with any wild eco-system, where “survival of the fittest” and “evolution by natural selection” are the ground rules to survival, IT companies, specifically, ABC Limited, changes it processes to incorporate SCRUM’s practices.

“Taking a more optimistic picture, the company ABC Limited, spends valuable resources, to dig deep and clean and modify its processes from the roots, rather than just batch renaming their processes to “agile”-processes. Come launch day, a brand new project (of a customer that demanded SCRUM) is asked to pilot it.

“The project team is trained in the specific workings of SCRUM. They are told:

1. Thou shalt not change thy commitment during the Sprint
2. Thou shalt have Daily Scrums for the team members to update each other on progress and impediments
3. Thou shalt have a ScrumMaster, who shall not manage, but facilitate
4. Thy Product Owner will not interfere on a daily basis (micro-management)
5. Thee and only thee is responsible for estimating and taking ownership of tasks and deliverables
   

“When the project starts the worker ants get busy. All motivated by and enthusiastic of this new framework, they are confident that they will be able to achieve all their targets. All is well until, the customer calls to change a specification and the team is asked to accommodate the urgent request in the Sprint. Next week comes, and the customer has more changes. Slowly, by the last sprint, changes are common, re-work is high and the team’s confidence on SCRUM is low.

“In the meantime, the project manager in his new avatar as the ScrumMaster has been trying to manage and control the team throughout the execution of the project. He ends up estimating and assigning tasks to the team. The Product Owner starts demanding daily status reports on the progress of the team which now becomes the main agenda of the Daily Scrums.

“In time the project fails to meet its desired state and the customer blames the team, who in turn blame SCRUM.”

This is not an out-of-the-blue case study. It is pretty much the fact across all organizations that claim to be Agile but in all practical sense, are not.

Adopting agile practices, in this case SCRUM’s practices, is not about adopting only what is felt beneficial, but all the practices as a whole. It is a package deal. It is not about just renaming processes to hoodwink customers into believing otherwise.

Neither customers nor the teams working on projects are at a liberty to discard or adopt practices as they feel fit.

Adopting SCRUM has a lot of advantages – both for the team as well as the customer. But for it to be successful, it needs to be understood completely by both parties.

Both parties need to understand their respective responsibilities in this game called SCRUM. Customers need to understand that micro-managing, asking for daily status updates and changing requirements on the fly is NOT allowed. Project teams need to understand the severity of their commitments to Sprints. And it is a Catch-22 situation.

Customers do not have confidence in commitments of project teams to go blind for the length of the Sprint and hence feel the need to micro-manage. Since, the project team no longer self-manages itself and the Sprint, the commitment they make is no longer strong.

So, this brings up the most obvious question in our minds. Where can true SCRUM practices be implemented? My most unintelligent guess would be – the Product companies. The teams (including all the way to the VP of the product) in such companies have more control over the features, technology and the execution process than typical service companies. While they still have market pressures, the buck still stops within the organization and that makes all the difference.

To support my argument, I have not come across any presentation or article that has a list of service companies in the list of top users of SCRUM. It may however list a part of the service company that is considered to be, not a vendor or a partner, but an extended arm of the customer’s development team itself. In that case, there is not too much of a difference between the customer and the offshore development center of a vendor that it controls.

Bottom line

For the apparent business reason, it is very difficult for a service company to say ‘No’ to its customers. It is even a bigger challenge to ask them to hold on to the change requests till the end of the sprint. And unless the customers are themselves geared up to speed, this golden rule of SCRUM will inadvertently be broken.

And this is the real reason why SCRUM cannot be implemented in IT services companies; at least not without making real changes in processes of both the vendor and the customer. And until someone comes up with a model that suits this kind of multi-location contract based development, I’d recommend not forcing SCRUM down our own throats and make it another CMMi-like fad.

Yet another Agile methodology

Based on my experience with projects, its teams and the customers and by doing a simple analysis of what are the most common pain points of these three entities, I have come to an approach that can be applied in the world of Offshore Contractual Software Development (OCSD). By OCSD, I mean all IT companies in the world that provide services such as software development, testing, or maintenance of existing systems to external customers that are not located in the same location (most commonly – in another country).

I came up with this approach by simply collating a list of all the problems that the customer and the vendor teams would want to do away with, thereby benefitting from its absence. I took the 6 most common problem statements (and presumably the most troublesome) from the list to derive this methodology.

The Six Most Common Pain Points (in no particular order):

1. Less or No Visibility / Lack of Effective Communication Mechanism: Customers often complain that they have no clue of what happens in the projects they are sponsor. Project teams work in silos and provide no or little information about the problems faced in the project or the execution status. The customers also would prefer some visibility of the product during the development cycle.

2. No Improvement in Processes: Project teams find it hard to change existing processes for the lack of empirical data. Imbibing of good practices and avoidance of impediments would help the project teams to plan and perform better; but existing methods to capture such information in the organization is a painstaking task with (sometimes) heavy and subjective templates to be filled.

3. Bloated Software: Most of the times both customers and vendors realize late in the stages of development, that the features that are developed add no or little business value to the users. At this point, customers (and sometime vendors) change requirements or chop features to make the application lean. This results in hefty re-work and decreases the stability of the system.

4. Poor Quality: If this list was ordered in ascending ranks of problem statements, this one would be on the top. While customers complain frequently on the poor quality of deliverables from project teams, the project teams in turn blame inadequate time lines and frequent change requests for this monster’s existence. Whatever the reason maybe, we might be able to salvage this problem.

5. Effort and Schedule Overruns: Incorrect estimations, re-work (due to any reason) and inconsistent planning are the usual culprits for effort and schedule overruns. Overruns such as these cost vendors and customers up to 300% of the actual contractual obligations, averaging at 60% most of the times.

6. Ever Changing Requirements: Customers are meant to be finicky, but their nature causes many projects to miss their quality, schedule or budgeted cost goals. If requirements can be frozen, approximately 80-85% of projects would not fail to deliver as promised.

My concoction to reduce most head-aches

Based on the list I presented above, I created a hybrid process using practices of three different agile methodologies. Here is the recipe of practices I recommend as “must have” with additional practices as optional condiments.

Must Have Practices (Set One) – Increasing Visibility

Deliver Frequently (Also known as ‘Small Releases’ in Extreme Programming and ‘Frequent Delivery of Products’ in DSDM).

This practices suggests that you have frequent releases of “potentially shippable software” that allows the customers to see gradual (and incremental) progress during the execution of the project. The frequency is suggested to be between 1 – 4 weeks in length and at the end of every such period some functional piece of software must be delivered or demonstrated to the customer.

This is possible with the adoption of iterative and incremental development approach.

The frequency at which release are made also depends on the volatility of requirements. Higher the rate of change requests, shorter should be the duration.

Optional Practice

Whole Team – Extreme Programming (Also known as ‘Active User Involvement’ in DSDM)

This practice involves not only the project team members, but also Customer teams and End Users in an active dialog to verify and validate the progress.

Must Have Practices (Set Two) – Improve Processes

Daily Scrums, Sprint Retrospectives – Scrum (Also known as ‘Continuous Improvement’ in Extreme Programming)

The purpose of this practices is to communicate – ‘What works’ and ‘What Could Work Better’.

Daily Scrums are internal team meetings where the team members inform each other on task updates and problems they faced. Sprint Retrospectives are done at the end of iterations to identify good practices and problems that can be avoided in future sprints. Thereby, fine tuning existing processes to work better.

Must Have Practice (Set Three) – Right Features for Best Business Value

Design Improvements & Simple Design – Extreme Programming, Fitness for Purpose (DSDM)

Constant design improvements during the life cycle of the project help identify unnecessary functionality and also prioritize features that would result in higher ROIs for the customer. Weeding out dead weight from the project will result also in higher productivity and better quality.

This can be done as a part of planning or retrospective meetings by the team involving the customers and end users. Demos at the end of iterations also help the customer/end users to realize what is important to them and what is not.

Must Have Practices (Set Four) – Increasing Quality

Code Standard – Extreme Programming, Continuous Testing – Extreme Programming (Also known as ‘Integrated Testing’ in DSDM)

Defining Coding Standards and Guidelines for project teams to follow will help in standardizing and maintaining the quality of code. Practices such as continuous testing allow project teams to identify defects early on during the development compared to the late detection of defects as in the Waterfall model.

Optional Practice

Pair Programming – Extreme Programming

Another method of organizing development teams is to pair programmers to work together on the same piece of work on one terminal that is shared between the two. One writes the code (called the driver), while the other one reviews it in parallel (called the navigator). The pair takes turns in playing each role. This pair is also rotated on other tasks. Two of the primary advantages of this practice are that two minds work on the same code resulting in better logic and the fact the code is reviewed as it is written, resulting in better code sooner.

Must Have Practices (Set Five) – Sticking to Planned Effort and Schedules

Planning Game – Extreme Programming (Also known as ‘Planning Poker’ in Scrum)

Sustainable Pace – Extreme Programming

As per agile practices, the estimation for effort and scheduling needs to be done by the project team and not managers or customers. The team will based on their experience suggest the amount of effort and time that it will take to carry out tasks. This leads to a stronger commitment from the team and increases their productivity since they now have full responsibility and accountability of sticking to their commitments.

Sustainable Pace suggests that the team work at a sustained pace through the project (for e.g. 40 hours/week) and avoid spikes in effort to meet deadlines. Planning that is carried out keeping in mind this practice is more effective and realistic.

Optional Practices

Self Organizing/Managing Teams – Scrum (Also known as ‘Empowered Teams’ in DSDM)

Giving the team the responsibility of planning and estimating may not be enough. It is advisable that the team is also empowered to meet their commitments. Hence, having a self managed team proves beneficial to the project.

Generating Burn-down Charts – Scrum

A burn-down chart reflects on the progress the team has made so far in the iteration. It is a graphical representation of the current velocity of execution of the team versus a steady pace. This allows the team to visualize the amount of work remaining and hence move things to a higher gear.

Must Have Practices (Set Six) – Stabilizing Requirements

Product Backlog – Scrum (Also known as ‘Base-lining Requirements at a High Level’ in DSDM)

Sprint Backlog – Scrum

A Product Backlog is a list of all functional and non-functional requirements of the project. It may also include tasks that need to be carried out to clear impediments or resolve dependencies. Having a product backlog allows the team to see a larger picture, though only the requirements that will go into immediate production need to be detailed.

A Sprint Backlog on the other hand is a sub-set of the Product Backlog and contains only those requirements/tasks that the team is undertaking for the current iteration.

While the iteration is in progress, the customer (Product Owner) is free to modify all product backlog items except those that have moved to the sprint backlog.

As mentioned above in practices set one, if the requirements volatility is high, then it is better to have shorter durations for iterations.

As you might have noticed, even though the practices are categorized as per the problem statement it immediately solves, it also would help reducing or eliminating other problem which might not figure in the List of Six.

Disclaimer

These practices have been borrowed from various agile methodologies, but each of these methodologies have more practices that it suggests implementation. And since, we do not in this concoction of practices implement all practices of a particular methodology, we should not claim to be practicing that methodology. However, by taking a dose of this mix, you can claim to be “agile”.

All credit for defining the above practices go to organizations of respective agile methodologies. But however, I take full credit for this tangy cocktail!

Two in the hand is better than one in the bush

Every couple of months or years, people from our industry, try to find better ways of creating products with better quality and faster turnaround. One such initiative is the Extreme Programming methodology or XP as it is more commonly called. XP lays down couple of best practices that are proven to enhance productivity of teams across the globe and one such best practice is one that addresses generating better code.

Pair programming is a practice that requires two developers working together on one workstation. Each member of this two people team is doing something that the other is not currently doing. For e.g., if one is writing a function, the other thinks about how the output of this function will affect the other pieces of code in the class.

The person who is typing is called a driver while the other, who is doing the analyzing, is called the navigator. At the end of a specific period, they switch roles and end of a longer period, partners (usually at the end of a module/task or end of day).

And like everything in the world that follows the yin-yang principle, pair programming has it’s pros and cons. The effect of it application in a project purely depends on the dynamics of the project and the mindsets of its team. I, however feel that the pros outweigh the cons and hence will be listing down the advantages of it.

Increase discipline – Having a pair of eyes look at everything you do tends to influence people to put their best foot forward. It makes people think better and work smarter. It also tends to cut down the breaks that a person takes, since the other’s work is dependent on what s/he does.
Though most people tout this benefit as a watchdog approach, it is not so. The navigator is not a silent spectator judging every move of the driver. This approach takes advantage of the psychological fact the people behave more responsibly in the presence of others.

Better code – Furthering the first benefit listed above, since the navigator is continuously applying his/her mind to think forward, s/he tends to review the code in a better fashion and hence increasing the quality of design and code.

Resilient Flow – Having another person around helps keeping the flow of the activity and maintaining its direction. It’s easier to get back on track if the flow is disrupted. Also, pairs are more resilient to interruptions. If there is an interruption, one can address it while the other continues working.

Multiple contributors to design – Due to the continual rotation of the pairs, everyone is involved in the development of the application. This brings in clarity of design and the opportunity to improve it.

Improved morale - Due to the fact that one is switching tasks with others, it increases competition amongst the team to produce better code. It even increases camaraderie in the team.

Collective Code Ownership – Since everyone has worked on the code, there is no single ownership. Everyone is responsible of every aspect of the code.

Improved understanding of the system – Pair and rotation results in everyone having an improved understanding of the entire system and not just specific modules that they would work on if they were not paired and rotated.

Mentoring – Technical mentoring is painlessly possible using paired programming techniques. This allows the junior members to gain more knowledge that the tradition knowledge transfer.

Lower hardware overheads – Fewer workstations are required since one is shared by two people.

As mentioned earlier, Paired programming does have its list of downfalls, but industry experts state that disadvantages such as increased cost, longer turnaround times, etc are usually short term. Once the practice is institutionalized, teams and organizations have realized that paired programming eventually does result in higher and better productivity, lower reworks and hence cost savings.

For further reading, follow the links below that I have referenced:
http://en.wikipedia.org/wiki/Pair_programming
http://c2.com/cgi/wiki?PairProgrammingPattern
http://www.methodsandtools.com/archive/archive.php?id=10
http://www.comp.polyu.edu.hk/people/doc/cskcchan/pairpaper.pdf http://theagileblog.net/2005/11/stop_demanding_pair_programmin_1.html