From the discussion with @JanVladimirMostert I understand, that your (as in "your friend's", I am just being lazy here :) ) company is rather small (100 employees is not a whole lot), except you meant the team size, which then would be awefully large. In case it really is just a company of a hundred people, introducing Agile is an easy feat :)

Convincing someone of Agile can be an easy task, depending on the person. In general you should start by asking questions: "When adopting a new way of working (e.g. Agile patterns), what are your main concerns? What kind of improvements do new standards have to offer in order for you to consider them?" That person might give you answer items which are important to them ("better productivity"), but might also have some missunderstandings about the new patterns ("Agile is a too big burden for us. The standard-overhead is too great"). Take a whole lot of time to listen before countering one single argument. Just listen and take notes until they do not have any more arguments. Your task then is not to show them how great Agile is, but to dispel any missunderstandings and reassure them that the technique is just what they are looking for. Normally, they will be a lot more cooperative after you countered all their arguments in an understandable and productive way (do not make them feel inferior, dumb or start an argument. Be professional!).

After having the support of your superior (boss / V.P. / ...), propose to be an advocate for the new practices. Try to find more colleagues with the same mindset and knowledge and make them advocates as well. Try to follow a top-down ╋ bottom-up approach to spread any new techniques.

Depending on what kind of work the company does, different Agile techniques might be employed. Pair-Programming is, just like you said, very nice in order to teach juniors (I successfully did it myself with several of my colleagues in order to teach them Web Development). If the company works on lots of small projects which have to be made-to-order, you might want to think about Agile Staffing, meaning people will be joined into teams depending on their skills. If the company builds big software products which have to be developed and maintained over a long period of time, the Skateboard Principle (MVP) and Kanban+Scrum might be the way to go. It is important that you take a lot of time to plan what to use and to which extend. Also it is important to gradually introduce all those new standards in order to get the other employees used to them in a comfortable manner.

One last warning: Agile techniques are very often implemented in a wrong way, resulting in demotivated employees, slow results and very high costs. Be sure you really know what you do when talking Agile. If in doubt, get a professional consultant.

Which agile process do you plan to use and what process are you currently following?

What type of company is it? (startup / corporate)

I rarely see any benefits doing pair programming, it's like using two dev resources to do the job of one person. Opinions differ though: developer.atlassian.com/blog/2015/05/try-pair-pro…