The main idea behind the agile methods is to help you be productive - in a positive sense. No one cares if you spend an hour surfing every day if you meet the deadline. Everyone gets mad if you surf half an hour every day but miss your deadline. The solution: Make it easier for you to meet the deadline.
As you noticed, pair programming makes sure you stay focused (among all the other advantages like improving skill/knowledge spreading, better code, less bugs, uniform design, etc.).
I found that discipline is always a struggle for me. If I pair with someone, chances are that one of us wants some work done today and pulls the other along. So the "work for a month" often becomes turns into "work together for one week", being surprised how that huge amount of work resolved in the end, spend a day or so recovering (refactoring, fixing TODOs in the code, adding a couple of tests, surfing with a clear conscience) and then grabbing the next month of work.
Net result: I'm much more relaxed (more because than despite the constant supervision), team cohesion is much better, work gets done more quickly, people don't hang around some minor issue for hours or even days (because someone else can spot the problem much faster).
When you say "you may actually feel ashamed", isn't that a good thing? It means you feel that you did wrong and you should. You're not getting paid to get nothing done. Not getting anything done makes you feel helpless, unhappy, unworthy, miserable. Instead of feeling ashamed, stand back and think "Why didn't I accomplish anything today?" Do you need help? Is there something you don't understand? Is the current task too hard? You don't like it? Maybe you can switch the task with someone else. Maybe someone else can help you get through. Agile means: Assume responsibility instead of being micro-managed like a puppet on strings. You need a tool? Go to your boss and ask for it. Learn to argue. Learn to stand up and shout when you have to.
As for tests, there is a sweet spot when your code suddenly collapses from "nice" to "perfect". That's the moment when you notice that you need to implement feature X and you thought that will be a nightmare and suddenly realize that the code is almost there. Just a small refactoring here and there. A new class and done. Four weeks of work suddenly became a day. Victory! Triumph!
Pair Programming is difficult.
It's difficult because it works best when the 2 people involved are close in skill level and that can be difficult in some work environments. It can be more difficult when you swap out because you need to find someone else with the appropriate skill level and then bring them up to speed on the current problem. The benefit is more people have exposure to any given piece of code that has been paired on. This should lead fewer times where code can't get fixed because no one knows enough about it. It should also propagate group ownership and the ability for anyone to pick up any piece of work.
I have found that even in environments where pairing is done, pair swapping is not worth the cost. However, this may be due to our tasks never taking more than ~1.5 days. We found a great benefit to breaking tasks down to be no bigger than ~1.5 days worth of work. Pair swapping may make more sense in the context of longer running tasks.
Best Answer
There's a lot of different styles, methods and mindsets related to the whole field development, and everything has it's own, shiny name.
Agile is just a mindset that moves away from the usual, static programming models (like waterfalls) - it's primary goal is to achieve more flexible development and (at the very end) better software and happy customers. Below agile, there are a lot of different models like Scrum, Kanban, XP.
Especially Kanban doesn't come from software development originally, it originates in building cars (i remind Toyota introduced it for building cars and some software developers adopted and expanded it)
Pair programming, code reviews and such stuff are just tools - you can (and should) always do it during a project, regardless which method you use. It's just that this stuff is more native to agile than to static.
XP more or less introduced these things (or at least gave them a shiny name) and all the following stuff adopted them because it simply worked out good.