I like XP (extreme programming), especially the part where there are 2 programmers at the same screen, since a problem's solution is often found more quickly if only you explain what you're doing and pair programming forces you to explain what you're doing.

Over the last 10 years or so, the XP style of working seems to have gone out of date in favor of the working methodologies: Agile and/or Kanban. Why? Since XP seems to me to be a very good way to work and is a lot about the programming whereas Agile and Kanban are more about processes.

  • 29
    XP is an agile approach. So "Agile" can't really replace XP. Commented Oct 9, 2012 at 6:44

6 Answers 6


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.

  • 3
    As @refro too mentioned, Scrum and Kanban don't include pair programming or code reviews (but neither do they exclude these). Both are more of a project management methodology than a software development process. And as such, they are applicable to a wide range of fields outside software development. Whereas XP is specifically a software development approach. These can coexist - you can manage your XP team in the Scrum way. Commented Oct 9, 2012 at 7:13

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.

  • 1
    Pair programming is like jamming in musician practices. It works sometimes and sometimes does not work at all. In rare cases it could be adopted as a general way to play and in very rare cases as way to compose.
    – Alex Yu
    Commented Jan 13, 2019 at 11:40

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.

  • 1
    Well Stated. XP was atrociously non marketable out the gate because it requires two salaries per task. This has the front-loaded problem of hoping that the productivity overall later pays for itself 2x per person. When the results didn't match, then in order to compensate (remember, all budgets are finite and all expectations wander to infinity), there is a knee-jerk reaction to hire less qualified engineers to make the numbers work. Commented Dec 5, 2020 at 22:16
  • "two salaries per task", interesting way to see XP :) Thank you @tgm1024--Monicawasmistreated Commented Dec 6, 2020 at 11:39

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.

  • There are a couple things I always keep in mind. 1. People love to declare a new way of doing things, and then declare victory in doing so, usually long before there's any proof. And 2. Folks seem to disregard that that the "individual lone wolves" programmer paradigm formed early perhaps for a reason. Similar to how people didn't understand why engineers so often needed to show up at 11 and leave at 1am, these things form from fundamental traits of highly abstract minds, not mere bad habits. Commented Dec 5, 2020 at 22:10

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.