I am an advocate of paired programming. A lot of organizations do it really poorly. Your examples show exactly where it does not work. First off, sometimes you

I am an advocate of paired programming. A lot of organizations do it really poorly. Your examples show exactly where it does not work. First off, sometimes you have a bunch of minor tasks that need to be taken care of, like updating some text in the UI or fixing a button size, also in the UI. Is there a reason that you have to sit down and plan to only do that? If you have a well prioritized backlog and the freedom to get work done these scenario's should be more like: "Let's work on adding this new feature here." "Ok that's a good one, we'll need to do a, b, and c to get it all wired up, working and tested. Hey since we're in that part of the code there are some small tasks about changing the button size and the text here, let's make sure to get those done." ... "Great! we completed the new feature, fixed the button size, and the text. Merge it!" I never sat down with my pair for the day and said "Ok go fix that button. Great, merge that. What's next?" It was always a discussion of the most valuable thing to get done and any collateral issues that could also be fixed. In this case, we often got more done. Second, if you had a pair partner sitting around doing nothing, there is a problem. They aren't engaged. They either need to become engaged or not be in an environment where there is paired programming. That is ok! But they need to admit it and move on. Pairing works well if you have the people and processes in place to allow it to work well. If there are people sitting on their hands, then there is a problem. Though I would argue that if you took away paired programming, the same engineers would often still be sitting on their hands, playing on facebook.