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.

In my view XP is a programming practices, Scrum and kanban are project management practices. They have a relation but do not replace each other.

In our kanban project we use pair programming (mostly for complex sections and debugging), TDD, CI. So it is still used but management is pushing the project management side harder.

Agile is more marketable because it involves different stakeholders with different roles and responsibilities related to the software building process.

When in its second edition Kent Beck enlarged the scope of participants within XP, it was late: people already embraced other methodologies because the first XP version targets the doers of the code, and that is what the audience still remembers of either unconsciously or not. XP was not marketable at birth.

Extreme Programming is about the mechanics of development, whereas Agile is about the SDLC (software development life cycle).

The main reason you don’t hear about “Extreme Programming” by name anymore is the use of the term “Extreme” as a positive adjective is an outdated 90’s-to-early-00’s thing that is seen as corny now. It’s mostly just a victim of marketing. That’s why you almost exclusively hear it referred to as “XP”, even verbally.

I have some thoughts about pair programming.

To me this is something you do when you are stuck with something. At those times it can be very effective, it can get you out of a rut. But it is also tiring and a way of working that the stereo type programmer does not like to do more than occasionally.

If you are digging a hole, few people would mind getting help from a co-worker. But as soon as there is creativity involved people prefer to do things their way rather than someone else’s way. So tension is always near unless one doesn’t care one way or the other or if one’s role is clearly to suggest only.

Where I work pair programming is not formalized but we do have ad hoc sessions and they are typically brief. It won’t be like “Hey co-worker, how about some extreme programming?” It would more often start with “Can you have a look at my screen?” and pulling up a chair for them.

So I do not think pair programming is dead or less popular, it is just one of those tools you do not use very often because it is costly, and not primarily because you have two payed people working on one thing.

I’ve always thought that Scrum was the version of Agile that was easiest to sell to management: the deterministic estimates, its somewhat doctrinaire, well-defined nature (“you’re not really doing Scrum – feel guilty!”)…

Stretch out your sprints long enough, and take those little “poker cards” seriously enough, and Scrum can very much tickle the same itch that Waterfall methods did. This is not necessarily bad, but let’s not hide behind smoke-and-mirrors here.

On the XP side, pair programming does not generally appeal to management, especially non-technical management.

To put it in SAT analogy format, Scrum:XP :: The Monkees:The Beatles