1. Transitioning to Pair Programming by Choice
1.1. Adopted more when developers
1.1.1. have increased choice in when to use that innovation
1.1.2. have decreased process control in how to use that innovation
1.1.2.1. Can't be told how exactly to do it
1.1.2.2. Can't be wild wild west, teams need some level of consistent organizational standards and procedures
1.1.3. their manager encouraged them to use the innovative technique
1.1.3.1. discourage "if you want to pair, go ahead and pair - I don't care" attitude
1.1.4. the innovation increases the predictability of their work
1.1.4.1. pairing results from University of Utah performed more consistently and predictably than individuals
1.2. manager introduction
1.2.1. Be the Local Leader and also the Evangelist
1.2.2. Ask a Respected Techie to read about pair programming
1.2.2.1. Let him/her try it
1.2.2.2. Don't rush this process
1.2.2.3. It is important for this person to genuinely be convinced of the technique through experience
1.2.2.3.1. If they are not, ask them to not publicly criticize and pick another Respected Techie
1.2.2.4. Encourage the Respected Techie to gain the support of other programmers
1.2.2.4.1. ask this group to organize a Pair Programming Tutorial
1.2.3. Organize an educational session for a larger organization
1.2.3.1. Run by the senior developers without management present
1.2.3.1.1. Should be prepared with a "Personal Touch"
1.2.3.1.2. bring up the negative things you have heard or anticipate audience bringing up
1.2.4. The Desired Accomplishments
1.2.4.1. Programmers who are interested in trying should sign up
1.2.4.1.1. team should develop an informal plan for who should try pairing with whom
1.2.4.2. Initial trial of technique should feel low risk for all invovled
1.2.4.3. Put in place a system of feeding back concerns and successes of these trials
1.2.4.3.1. can be as informal as stopping by senior programmers desk periodically
1.2.4.3.2. can be as formal as tracking progress / defects
1.2.4.4. Team should then discuss what would convince them that pair programming is or is not a valid technique
1.2.4.4.1. should decide what data they want to collect and how long it will take for them to decide on the validity of the technique
1.2.4.5. Team should discuss organizational guidelines for use of pairing
1.2.4.5.1. example
1.2.5. Involve Everyone
1.2.5.1. including skeptics
1.2.5.1.1. maybe pair an early adopter with a skeptic
1.3. Advice for Programmers
1.3.1. suspend disbelief and don't make threats
1.3.1.1. you never know what you might learn and too quick a reaction will make it all that much harder
1.3.1.2. form opinions after trying it for a couple of weeks
1.3.2. pretend it will work to give it a fair shot
2. Problem, Problems
2.1. Dependency
2.1.1. Becomes harder for developers to program alone
2.1.1.1. If you're alone, find another partner, or help be the second with someone else
2.1.2. They feel less confidant and can grow dependent of the partner
2.1.2.1. Always review what was done alone, with the pair, this will help keep things moving but still have confidant and allow for review and bug catching
2.2. Scheduling
2.2.1. Can be more difficult to schedule
2.2.1.1. Can be easy if always pairing with the same person
2.2.2. A lot of benefits to rotating pairs, so it needs to be managed
2.2.2.1. my ideas
2.2.2.1.1. Scrum bullpen environment
2.2.2.1.2. Meetings are often unnecessary - skip and continue to do work
2.3. The Ever-Popular Expert
2.3.1. Continuation of the scheduling problem
2.3.2. NOT a problem with scrum
2.3.3. GUI / Database / Kernal experts
2.3.3.1. Best to let them have time to work their critical tasks alone
2.3.3.2. potentially set up office hours
2.3.3.2.1. ( again, not a problem when using scrum )
2.4. Colocation
2.4.1. People come in to work at different times and have different schedules
2.4.2. Balance between the needs of the project and the needs of the employees
2.4.2.1. core pair programming hours
2.4.3. Remote workers - distributed pair programming
2.4.3.1. not as effective but it can be a valid option
2.5. Noise and Facility Considerations
2.5.1. requires a commitment from the organization in terms of facility changes.
2.5.2. more appropriate desk setups / cubicle space
2.6. Concentration
2.6.1. You can still work alone for a truly creative requirement and then come back together with a pair to discuss conclusions
2.6.1.1. Be open to revising your brainstormed-in-isolation solution
2.6.1.2. Most certainly, your partner can think of something you didn't think of when you were alone
2.7. Disagreements
2.7.1. Strategies for resolving conflicts
2.7.1.1. each of you go off alone for a specified period of time to cool off and investigate what you feel so strongly about
2.7.1.2. Take a walk around the building -- together!
2.8. Overconfidence
2.8.1. Sometimes a pair can feel they can do no wrong when working together
2.9. Rushing
2.9.1. Highly effective teams can sometimes feel a need to complete a task during a session.
2.9.1.1. Sometimes you need to not rush a solution and resolve it next session
2.10. Skill Imbalances
2.10.1. Pair new team members with mentoring types to keep them feeling welcome and limit frustrations
2.10.1.1. Mentor needs to give up control and allow the less skilled to drive most of the time
2.11. Simply Not for All
2.11.1. Might not work for someone
2.11.1.1. too introverted, soft spoken, or lacks confidence
2.11.1.1.1. Might grow into it with pairing of a great mentor or another very similar introvert
2.11.1.2. too self centred, egotistical or feels threatened
3. Workplace Layout
3.1. Basic Needs
3.1.1. sit comfortably side by side
3.1.2. both can completely view the monitors
3.2. Suggested Workplace Enhancements
3.2.1. Cave and Commons
3.2.1.1. Outer cubbies for devs to call home
3.2.1.1.1. may or may not have computers
3.2.1.1.2. a private space to decorate and take phone calls
3.2.1.2. primary focus is on pairing stations at tables in the center for the team to work together optimally
3.2.2. 1 Computer, 2 Displays, 2 Keyboards, 2 Mice
3.3. Interpair Communications
3.3.1. Pairs need to be able to hear others pairs on the team
3.3.2. There is a lot of benefits to overhearing other conversations to help each other out even when not directly communicating
3.4. Development Environment
3.4.1. Ideally there is a standardized enviornment
3.4.2. The team needs to agree to program in a different environment for at least half the time for the next 'n' weeks
3.4.2.1. 'n' doens't have to be too high before they decide they can converge on a single enviornment
4. Pair Rotation: Communication, Knowledge Management, and Training
4.1. Pair Rotation
4.1.1. Usually happens very casually without any formal schedule
4.1.1.1. Teams learn to choose the right partner for the right situation
4.1.2. Easiest to stomach and accomplish with small tasks (< week)
4.1.3. Partner Assignment
4.1.3.1. Daily Scrum a good time to identify when we can help each other and self identify to pair with someone
4.1.3.2. Just say yes strategy
4.1.3.2.1. When someone takes a task they ask someone to pair with them and said someone can't say no
4.2. Training
4.2.1. Pairing can reduce training time by a factor of two compared to not pairing
4.2.2. Split the team into 'Progress' team and 'Training' team
4.2.2.1. Training team is made of mentors and new team members
4.2.2.2. As team members pair and gain enough experience they transition to the progress team
5. Other Issues to Consider
5.1. Performance Appraisals
5.1.1. Companies often focus on individual performance
5.1.2. Switch to utilize peer evaluations
5.1.2.1. After all, who knows better?
5.1.2.2. Ask the employee for 3 names of who to have peer evaluate, and 3 names of who should NOT peer evaluate to give a guideline on personal conflicts
5.2. Team Size
5.2.1. keep it small (scrum team size applies)
5.2.2. Try to have even number teams =)
5.3. Quality Assurance
5.3.1. Pair Programming is another QA checkpoint which will reduce bugs and improve quality heavily
5.3.2. 'Formal Testing' time is often reduced due to all the benefits
5.3.3. Peer reviews also go smoother or become obsolete at times
5.4. Functional and System Testing
5.4.1. Encourage testing be a pairing activity as well
6. Tips and Tricks
6.1. Give the driver a few nanoseconds to find and correct his or her own mistakes
6.1.1. Same for navigating menus etc
6.2. If your partner is getting bored pass them the keyboard
6.2.1. If both of you are tired, get up and walk around or take a break
6.3. If your partner is getting tired or frustrated, grab the keyboard
6.4. Come to an understanding on how pairing will work with a new pair
6.4.1. Negotiate on what each person likes to do and how. What each does well etc
6.4.2. Takes < 5 min
6.5. Handling Conflict
6.5.1. Navigator record (on cards) contentious issues that are bothering the driver.
6.5.1.1. Review every half hour.
6.5.1.2. This allows progress to continue but concerns to be addressed before it becomes too late
6.5.2. Separate for a period of time ~ 10 min
6.5.2.1. investigate on their own, take a walk
6.5.2.2. get back together to discuss their investigation
6.5.3. Let the navigator drive for 5 minutes
6.5.3.1. If driver agrees, driver can finish it out, if not he can roll back
6.5.3.2. Sometimes just trying can make both sides see the good and bad and lead to an agreement
6.6. Use a coding standard
6.6.1. Eliminates partner disagreement due to style
6.7. Use test driven development
6.7.1. Helps facilitate switching between driver and navigator
6.8. Practice active listening
6.8.1. Acknowledge, restate, and summarize ideas
6.9. Talk a lot
6.9.1. Talk about what you're diong
6.9.2. Explain techniques for using the development enviornment
6.10. If your partner is not listening at all, get up and walk away
6.11. Just ask!
6.11.1. If you don't understand what your partner is doing, stop and ask
6.11.1.1. Still don't get it? Ask again!
6.11.2. It can be tough to learn to talk while driving, help each other out. We aren't keeping secrets we just forget how to share them
6.12. Take enough showers, eat lots of breath mints
7. Pair Programming Partner Picking Principles
7.1. Partner Dynamics
7.1.1. Definitions
7.1.1.1. Average Programmer
7.1.1.1.1. Lots of experience but just average
7.1.1.1.2. Little experience becoming an expert
7.1.1.2. Novice Programmer
7.1.1.2.1. Doesn't necessarily mean new dev but maybe just new to the team
7.1.2. Expert-Average Pairing
7.1.2.1. Intent
7.1.2.1.1. Accomplish average job
7.1.2.1.2. Raising the skill level of one pgorammer
7.1.2.2. Characteristics of Success
7.1.2.2.1. Not Average 1 programmer, but an Average 2 programmer
7.1.2.2.2. Expert does some mentoring
7.1.2.3. Challenges
7.1.2.3.1. Average programmer really is average
7.1.2.3.2. Average programmer does not interact enough w/ the expert
7.1.2.3.3. Average programmer doesn't seem to "get it"
7.1.3. Expert-Novice Pairing
7.1.3.1. Intent
7.1.3.1.1. Get easy jobs done well while training a novice programmer
7.1.3.2. Characteristics of Success
7.1.3.2.1. Novice learning by watching the expert
7.1.3.2.2. Novice helps the expert do a better job
7.1.3.3. Challenges
7.1.3.3.1. Teacher like qualities in expert required
7.1.3.3.2. Comfortable environment that is nonthreatening
7.1.3.3.3. Expert not open to listening to advice from apprentice
7.1.4. Novice-Novice Pairing
7.1.4.1. Intent
7.1.4.1.1. Produce production code in a relatively noncomplex area of the project giving valuable experience to both programmers
7.1.4.2. Characteristics of Success
7.1.4.2.1. Helping each other learn
7.1.4.2.2. Together are willing to get help and move forward
7.1.4.2.3. Coach, instructor or mentor available to answer questions and help guide the pair
7.1.4.2.4. Works best in a class/teaching enviornment
7.1.4.3. Challenges
7.1.4.3.1. Easy for the pair to go down the wrong path
7.1.5. Extrovert-Extrovert Pairing
7.1.5.1. Intent
7.1.5.1.1. After long, thoughtful, constructive discussions, an excellent creative solution is created
7.1.5.2. Characteristics of Success
7.1.5.2.1. Pairing is all about communication, typically extroverts are the best communicators
7.1.5.2.2. Will often openly question decisions
7.1.5.3. Challenges
7.1.5.3.1. Loud and full of laughter
7.1.6. Extrovert-Introvert Pairing
7.1.6.1. Intent
7.1.6.1.1. Allow each partner to draw on his or her strengths and to improve upon his or her weakness
7.1.6.2. Characteristics of Success
7.1.6.2.1. Pairing still works in these groups
7.1.6.2.2. Extrovert must consciously work not to talk all the time and to draw valuable information from their partner
7.1.6.2.3. Introverts must speak up when there is a problem or if they disagree or don't understand
7.1.6.3. Challenges
7.1.6.3.1. Each partner must give up a little from their personality
7.1.7. Introvert-Introvert Pairing
7.1.7.1. Intent
7.1.7.1.1. A silent intensity leads to rock-solid solutions
7.1.7.2. Characteristics of Success
7.1.7.2.1. Maintain a decent level of interaction
7.1.7.2.2. not a lot of verbal communication but other means of communication
7.1.7.3. Challenges
7.1.7.3.1. Introverts can be very poor communicators
7.1.7.3.2. Introverts like to work locked away in a cave, they will strongly resist pairing
7.2. Nonissue Dynamicis
7.2.1. Gender Nonissue
7.2.1.1. Issue
7.2.1.1.1. Gender is not an issue
7.2.1.2. What This is About
7.2.1.2.1. Partner Dynamics still apply but gender makes no difference to them
7.2.1.2.2. Communication is the key and men and women communicate differently
7.2.1.3. If There are Problelms
7.2.1.3.1. Usually is Gender Disrespect
7.2.2. Culture Nonissue
7.2.2.1. Issue
7.2.2.1.1. Having pairs w/ different cultural backgrounds is wonderful for building trust and communication
7.2.2.2. What This is About
7.2.2.2.1. Culture doesn't matter as long as they communicate
7.2.2.2.2. Actually pair programming w/ culturally diverse team can help everyone understand each other and gain trust
7.2.2.3. If There are Problems
7.2.2.3.1. Cultural bigotry can exist in either partner
7.3. Real Problems
7.3.1. Professional Driver Problem
7.3.1.1. Root Cause
7.3.1.1.1. Desire for power, lack of confidence in partner, navigators lack of confidence in himself
7.3.1.2. General Form
7.3.1.2.1. driver will not give up control of keyboard
7.3.1.2.2. Driver unwilling to listen very much to navigator
7.3.1.2.3. Navigator feels disjointed, out of the loop, unimportant
7.3.1.3. Refactored Solution
7.3.1.3.1. Train driver on the benefits of pairing
7.3.1.3.2. Professional navigators must force themselves to take control
7.3.2. My Partner is a Total Loser and Other Excess Ego Problems
7.3.2.1. Root Cause
7.3.2.1.1. Attitude problem, usually nothing to do w/ the partner
7.3.2.1.2. the person just feels that he or she is better than anyone else
7.3.2.2. General Form
7.3.2.2.1. Partners can't stand to pair with the person
7.3.2.2.2. Intimidates his partner
7.3.2.2.3. Cohesion of the entire team becomes at risk
7.3.2.3. Refactored Solution
7.3.2.3.1. Best solution: Fire this person
7.3.2.3.2. Get known good partners to pair with them and show they can be valuable
7.3.2.3.3. Counsel the person and get them to acknowledge the problem and attempt to keep the ego in check
7.3.3. My Partner is SO Smart and Other Too Little Ego Problems
7.3.3.1. Root Cause
7.3.3.1.1. someone simply has zero confidence in themselves and feels inadequate in accomplishing even basic tasks
7.3.3.2. General Form
7.3.3.2.1. readily apparent
7.3.3.2.2. Have techniques to hide it - quiet, return questions instead of answering
7.3.3.2.3. "flip the bozo bit"
7.3.3.3. Refactored Solution
7.3.3.3.1. Let those who lack confidence drive
7.3.3.3.2. Pair them with someone with good people skills
8. Introduction
8.1. Definitions
8.1.1. Pair Programming
8.1.1.1. a style of programming in which two programmers work side by side at one computer, continually collaborating on the same design, algorithm, code or test
8.1.2. Driver
8.1.2.1. One of the pair typing at the computer or writing down a design
8.1.3. Navigator
8.1.3.1. Other partner which has many jobs
8.1.3.1.1. observe the work of the driver looking for defects
8.1.3.1.2. Strategic thinker
8.1.4. Programming
8.1.4.1. design, development, debugging, testing etc
8.2. Why Pair?
8.2.1. Quality
8.2.1.1. pairs produce code with fewer defects
8.2.2. Time
8.2.2.1. pairs produce higher quality code in about half the time as individuals
8.2.3. Morale
8.2.3.1. pair programmers are happier programmers
8.2.3.2. helps job retention
8.2.4. Trust & Teamwork
8.2.4.1. pair programmers get to know their teammates much better
8.2.4.1.1. builds trust and improves teamwork
8.2.5. Knowledge Transfer
8.2.5.1. pair programmers know more about the overall system
8.2.6. Enhanced Learning
8.2.6.1. pairs continually learn by watching how their partners
8.2.6.1.1. approach a task
8.2.6.1.2. use language capabilities
8.2.6.1.3. use development tools
8.2.6.1.4. etc
8.3. History
8.3.1. 1953 - Fred Brooks, author of The Mythical Man Month
8.3.1.1. "Bill Wright and I first tried pair programming when I was a grad student. We produced 1500 lines of defect-free code; it ran correctly first try"
8.3.2. 1970's - Dick Gabriel, concieved Common Lisp and introduced patterns
8.3.2.1. reports pair programming in 1970s
8.3.3. 1980's - Larry Constantine, author of more than 150 technical articles and 16 books
8.3.3.1. observed "Dynamic Duos" producing code faster and more bug-free than ever before.
8.3.3.2. Concluded two programmers in tandem was not redundancy, but rather it was a direct route to greater efficiency and better quaity
8.3.4. 1995 - James Coplien of the Pasteur project at Bell Labs Research
8.3.4.1. Published the "Developing in Pairs" Organizational Pattern
8.3.5. 2000 - Kent Beck, developed Extreme Programming (XP) methodolgy
8.3.5.1. Largest known group of pair programmers following XP
9. 7 Myths of Pair Programming
9.1. It will double the workload with two doing the work one can do
9.1.1. reality - proved by a 16 week study at University of Utah
9.1.1.1. Get two people programming in pairs and they'll work more than twice as fast as one could have
9.1.1.2. majority of buggy production code comes from individually written code
9.2. I'll never get to work alone. I Couldn't stand that!
9.2.1. reality - based off of different surveys
9.2.1.1. ~30% spent working alone
9.2.1.2. ~50% spent pairing
9.2.1.3. ~20% spent working with more than 2
9.3. It will work well only with the right partner
9.3.1. reality
9.3.1.1. works well with most (though not all)
9.3.1.2. usually those with excess ego and/or a 'my way or the highway' attitude is the exception
9.4. Pair programming is good for training. But, once you know what you're doing, it is a waste of time
9.4.1. reality
9.4.1.1. two experts solving complex problems will come with a great solution, always better than what they would have come up with individually
9.4.1.2. two experienced programmers will fill many of each other's knowledge gaps
9.4.1.2.1. Everyone has gaps
9.5. I'll never get credit for doing anything. I'll have to share all the recognition with my partner
9.5.1. reality
9.5.1.1. pairing is about better quality code and better solutions for the project and benefits the team overall
9.5.1.1.1. so desired personal success transitions to desired team success.
9.5.1.1.2. individual success means nothing without team success (sports analogy)
9.5.1.2. Need to put effort into peer evaluations
9.5.1.2.1. valuable feedback to management and peers
9.6. the navigator finds only syntax mistakes. Compilers can do that better than humans can.
9.6.1. reality
9.6.1.1. Navigator is doing more than syntax checks
9.6.1.2. Navigator is holding the roadmap and is caught up with staying between the lines on a winding road
9.6.1.3. Overall design is constantly being assessed and re-considered by navigator while driver implements the latest agreed on idea
9.6.1.4. Also help brainstorm - brainstorming concludes good designs much faster than individual considerations
9.7. Only time I ever get any real work done is when I'm alone.
9.7.1. reality
9.7.1.1. This idea comes from a desire to be in the 'flow' or the zone
9.7.1.1.1. the zone is a mythical desired state that is actually not optimal
9.7.1.1.2. Losing context or flow can happen with a 15 second interruption
9.7.1.1.3. A pair will get interrupted less than someone working individually at their desk
10. 7 Synergistic Behaviours of Pair Programming
10.1. Pair Pressure
10.1.1. pair programmers put a positive form of pressure on each other.
10.1.1.1. Programmers admit to working harder and smarter on programs because they do not want to let their partner down
10.2. Pair Negotiation
10.2.1. stemming from 'distributed cognition,' two pair programmers arrive at the best solution together
10.2.1.1. each brings his/her own set of skills, abilities and outlook
10.2.1.2. both share the same goal for completing the task
10.2.1.3. jointly approach a problem each with a suggested alternative for attacking it
10.2.1.4. must 'negotiate' how to approach the problem jointly
10.2.1.4.1. evaluate more alternatives than either one would have considered alone
10.2.1.5. efficiently determines which is the best plan of attack
10.2.1.6. 'high five' eachother for being so smart and kicking butt on the task
10.2.2. Improved adherence to procedures and team standards
10.3. Pair Courage
10.3.1. tremendous courage builder, giving us confidence to do things we might be afraid to do alone or simply might avoid and never do
10.3.1.1. Teacher analogy
10.3.1.1.1. Teacher asks all students to do a task and ask their answers at the end, only a few will respond
10.3.1.1.2. Teacher asks all students to work with a pair, nearly every pair will respond at the end, they are much more confidant in their answer
10.3.2. Strength in numbers!
10.3.3. Courage to admit when we don't know something
10.3.3.1. individually we would muddle through problems on our own embarrassed to ask others questions
10.3.3.2. in a pair we are much more likely to ask for help
10.3.3.3. Study shows 42% of developers are inclined to work on problems alone
10.3.3.3.1. the more experience a developer has the more likely he or she is to ask for help
10.4. Pair Reviews
10.4.1. 4 eyes are better than 2
10.4.2. Studies show peer reviews find defects earlier and the earlier a defect is found the cheaper it is to fix
10.4.2.1. pairing gives you minute by minute peer review, best way to find all bugs as early as possible
10.5. Pair Debugging
10.5.1. It is a common and effective practice to explain a problem to an inanimate object like a teddy bear or a duck and in explaining we come to conclude our problems
10.5.1.1. amplify this when talking to another person. The back and fourth with a human can lead to solving hard problems quickly
10.6. Pair Learning
10.6.1. Knowledge is constantly being passed between partners
10.6.1.1. tool usage tips to programming language rules to design and programming idioms
10.7. Pair Trust
10.7.1. Pairing allows teammates to open up to each other's knowledge and experiences and to see tha tthe end result is far better than anything they could have developed on their own
11. Overcoming Management Resistance
11.1. "I have to pay two programmers to do the job 1 could do
11.1.1. Wrong
11.1.1.1. The pair will get tasks done faster and with considerable less bugs
11.1.1.1.1. 1 bug equates an unknown amount of future effort that is hard to estimate but is agreed it's always better to catch a bug earlier
11.2. What's In It For Me Goals
11.2.1. I want to complete my project on time with high-quality code
11.2.1.1. 1996 Hill Air Force Base Report
11.2.1.1.1. Study where projects were to be done in two-person teams where EVERYTHING was done as a pair
11.2.1.2. 1998 Temple University Professor Nosek Reported a study of 15 full time experience programmers
11.2.1.2.1. working for 45 minutes on challenging problems, 5 individuals, 10 as pairs (5 pairs)
11.2.1.3. 1999 Study by authors- University of Utah - 28 students in the Senior Software Engineering course
11.2.1.3.1. Even mix of experienced students, individuals and pairs with the same assignments (pairs having extra work outside of the study to keep fair workload)
11.2.1.4. Industry data reports that between 33 and 88 hours are spent on each defect found in the field
11.2.1.4.1. When each defect saved during code development can save defect correction time of between .5 and 88 hours pair programming quickly becomes the cost-saving and time-saving alternative
11.2.1.5. Time to market is often half the time with pair programming
11.2.2. I want to reduce my risk of losing a key person
11.2.2.1. Multiple people are familiar with nearly every part of a system leaving no key persons
11.2.2.2. Truck number is 2+ depending on frequency of pair rotation
11.2.3. I want my employees to be happy
11.2.3.1. Happier employees stay in their jobs longer
11.2.3.2. Turnover is costly
11.2.3.3. Based on 7 independent surveys of self-selected pair programmers, over 90% of pair programmers agreed that they enjoyed their jobs more when pair programming
11.2.3.3.1. 96% indicated that pair programming made them more confident
11.2.4. I want to reduce the amount of time it takes to train a new person
11.2.4.1. training costs are reduced which helps me manage my budget
11.2.4.2. New people can actually contribute to projects much earlier
11.2.4.3. Pairing is training on actual tasks while traditional training does not contribute toward the completion of the project
11.2.4.3.1. teaching by doing and not showing which has been proven to be more effective
11.2.5. I want my teams to work well together and to communicate more effectively and efficiently with each other
11.2.5.1. My team works together better because they know each other and like each other
11.2.5.1.1. makes happier employees and reduces information islands
11.2.5.2. Pairing encourages interteam communications
11.2.5.2.1. without pairing often individuals would show up put their headphones on, eat alone and go home
11.2.5.2.2. Over time teams get closer, eat together, often have personal friendships outside of work
11.2.5.2.3. Rapport and trust builds
12. Gaining Support & Acceptance from Peers
12.1. Cites Introducing Patterns into Organizations (2002)
12.1.1. Evangelist
12.1.1.1. Gradually introduce casual, noninvasive use of the practice with your peers
12.1.1.2. "Test the Waters"
12.1.1.2.1. Identify people that seem especially interested in new ideas - innovators
12.1.1.3. "Just Do It"
12.1.1.3.1. Don't label it as "Pair Programming" - this makes people anxious
12.1.1.4. Grow the pairs to other parts of the team forming the "Early Majority"
12.1.1.4.1. This can lead to a "Grass Roots" effort
12.1.2. Local Leader
12.1.2.1. After you have an Early Majority talk to your management and get him/her to be a local leader
12.1.2.2. Track statistics
12.1.2.2.1. # of bugs before and after
12.1.2.2.2. first hand experience and discussion of productivity of the team
12.1.2.2.3. test results that show quality is improving
12.1.3. Brown Bag
12.1.3.1. lunch or department meeting
12.1.3.2. increase involvement and information about pair programming
13. Moving Ahead and Going Beyond
13.1. Triplets
13.1.1. three very experienced, mature and responsible
13.1.2. complex problem that justifies 3 brains
13.1.3. Keyboard, white board, and thinking out loud
13.2. Multidisciplinary Pairs
13.2.1. UI specialist with developer
13.2.2. tester and developer
13.2.3. Customer and developer
13.3. Projection Screen
13.3.1. No longer constrained by the desk
13.3.2. Supportive of triplet programming
13.4. Distributed Pair Programming
13.4.1. Don't perform as well as face to face pairing
13.4.2. Needs periodic face to face pairing to get to know each other and keep up with how to work together
13.4.3. Requires more verbal communication than ever
13.4.4. Seeing each other (web cams) is important for communication
14. Seven Habits of Effective Pair Programmers
14.1. Take Breaks
14.1.1. Check emails, return phone calls, etc
14.2. Practice Humility
14.2.1. It's okay to not know something, admit it and start helping the team as best you can
14.2.2. We all make mistakes, let others help you fix them before they go to prod.
14.3. Be Confident / Be Receptive
14.3.1. No judging, no competing with each other.
14.3.2. Work Together
14.4. Communicate
14.4.1. 15 sec without talking is long, 30 sec is an eternity
14.4.2. Programmers are stereotyped as quiet, but really they like to talk about what they are interested in, like programming
14.4.3. This is not a force of extroverts, this is excelling at what they do and showing colleagues and being shown by colleagues
14.5. Listen
14.5.1. Listen to details and try to stop assuming
14.6. Be a Team Player
14.6.1. Your partners work == your work
14.6.2. Use the word "we" a lot
14.6.3. If you don't understand something, ask, you are responsible for all of this work too