The Difference between Extreme Programming vs. Scrum

The whole "extreme programming vs. scrum" dilemma can be confusing, especially for newcomers to agile. Do these two approaches solve the same problems? Are they competitors? Can I use both? These are some of the questions that trouble engineers and engineering leadership when deciding which methodology to pick.

Extreme programming is a software development methodology, the goal of which is to satisfy the customer by delivering high-quality, valuable software at small intervals. Scrum is a framework for sustainably developing complex products, and you can use it with products other than software. This is actually one of the key differences between the two.

Extreme Programming: How It Works and How It Came To Be

Both XP (extreme programming) and scrum are approaches you can use to develop software in a lightweight, iterative way. They are part of what's collectively known as agile software development methodologies, or simply "agile." Agile development includes many other methodologies, such as Lean Development and Crystal Clear, among others.

So, since both XP and scrum belong to the same "category," a logical conclusion would be that they're competitors. Well, things are a little bit more complicated and more interesting. To understand how, let's dive deeper into both approaches.

What Is XP? How Does It Work?

In an XP project, work happens in short iterations that can last from one to three weeks. Before each iteration, a meeting happens where developers, managers, and the customer decide how much work can be done during that iteration. The customer prioritizes the work that needs to be done, and the team members commit to the amount of work they estimate they can deliver during the iteration.

Development starts, and the engineers start to implementing the project's features in the form of user stories. During development, engineers must follow the XP engineering practices:

using pair-programming when writing production code
writing unit tests before the production code (that is to say, using TDD)
the pairs must integrate their code often (i.e., do continuous integration)
refactoring the code as often as possible
adopting collective ownership of code

XP has several values that guide development:

Communication. Constant and transparent communication is essential for the success of a project.
Simplicity. Teams should implement exactly what was asked—and nothing more—striving for a simple design and clean code.
Feedback. Early and frequent feedback is essential, and it can take many forms: feedback from the automated unit tests, feedback from team members, feedback from the client itself.
Respect. Every member of the XP team deserves respect, as does the client.
Courage. Developers should give honest estimates, not create excuses for failures, and trust their coworkers to help the project succeed.

There's much more to it than that, though. XP also has other crucial components such as principles—meant to bridge the gap between the high-level values and the concrete practices and roles—which dictates the responsibilities of each member of the team.

A Brief History of XP

The origins of extreme programming date back to the first experiences of Kent Beck managing development teams:

The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.

Kent Beck

The Chrysler Comprehensive Compensation System, also known as C3, was the first acknowledged XP project. The approach used in this project actually helped to formalize the core principles and practices of the extreme programming methodology.

Scrum: Definition and History

Having covered the definition, workings, and history of XP, we'll do the same for scrum.

Scrum: Definition and Details

Scrum is a framework intended to help teams create solutions for complex problems in an adaptive/iterative manner. Right there, we see the first important difference between the two approaches: Scrum isn't only about software. So, how does scrum work?

Let's look at what scrum's official site says:

In a nutshell, scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat

The Scrum Team

In scrum, all of the work is done by a team comprised of:

A Scrum Master responsible for ensuring the scrum framework is properly followed.
The Product Owner (PO) responsible for managing the Product Backlog and ensuring the most valuable work is done.
The Developers who plan the work for each Sprint and perform the work to deliver the value prioritized by the PO.

Keep in mind that, in scrum, developers aren't necessarily "software developers." The group of developers can be quite diverse when it comes to the skills and expertise they have. This will vary according to the domain of the work itself.

How Does Scrum Work?

The work in scrum occurs in events:

The Sprint: the short cycle in which every work occurs. This can take up to a month, with preference given to the shortest length.
Sprint Planning: the event that starts the Sprint. This consists of a meeting where the team decides how to add value to the customers, the amount of work that can be done, and how it will be done.
Daily Scrum: a fifteen-minute meeting at the start of each day in which the developers talk about progress toward the goal of the sprint, making adjustments as necessary.
Sprint Review: a meeting that occurs at the end of each Sprint in which the team presents to stakeholders the results accomplished during the Sprint.
Sprint Retrospective: represents the end of the Sprint. It's an opportunity for the team to reflect upon the Sprint and how well it went and decide which changes could be made to improve the team's work.

There is much more to it than that, of course, with a whole glossary of scrum terms. However, the gist of it is the quote above. You might think that's very similar to the workflow of XP, and you'd be excused for doing so. Later, we'll address the similarities—and differences—between the two.

The Origins of Scrum

Jeff Sutherland and Ken Schwaber created scrum after reading a paper by Japanese researchers Hirotaka Takeuchi and Ikujiro Nonaka. In the paper, they discussed a new approach to product development inspired by the game of rugby.

The first scrum team started in 1994. In the following year, Ken Sutherland and Jeff Schwaber published a paper in which they introduced the scrum framework officially. Over the following years, the duo successfully introduced the framework to several different companies.

Extreme Programming vs. Scrum: Time for Some Comparison

Since they're both agile approaches, XP and scrum have a lot in common. They both dictate that work should be in an incremental way. Both approaches emphasize the importance of team autonomy, transparent communication, and prioritizing work that delivers the most value. In both approaches, requirements are broken down into small units. There are overlaps when it comes to roles as well. XP's customer and scrum's Product Owner play essentially the same role, for instance.

However, there are important differences as well. As we've already mentioned, scrum is a framework that teams and organizations can use to manage products of different types. Scrum doesn't dictate which software engineering practices developers should use, for instance.

Extreme programming, on the other hand, really cares about programming. It's in the name! This methodology puts a lot of emphasis on the programming techniques developers should use to ensure a high-quality result. Sure, XP also has practices, values, and roles that involve non-programmers. But from its very roots, XP has always been a more technical approach than scrum.

Scrum delegates to the developers the decision-making on how to do the work to generate the value for each Sprint. It doesn't have any say in how they will accomplish the work. Yet another difference between the approaches has to do with how rigidly you must adhere to them. The Scrum Guide states that you can't say you're using scrum if you don't adopt the whole of it. On the other hand, XP admits that not all parts of the approach will work the same for everyone. You should expect that XP will break, and you should fix it when that happens.

What's the verdict, then? Simple: XP and scrum aren't competitors. You certainly can use both, with scrum at the project management level and XP when it comes to the engineering practices developers use in their day-to-day work.

Remote Collaboration in Extreme Programming and Scrum: What Does It Look Like?

Some people say XP and scrum—and agile development in general—are outdated. They say agile principles such as face-to-face collaboration or even scrum practices such as the daily scrum don't make sense in the modern software industry. After all, so many of us are working remotely, synchronously or not. Are the naysayers right?

Well, they're right in that the agile methodologies had their genesis in the nineties, before words like Git, GitHub, and Cloud Computing were part of tech's lexicon. However, they're wrong in saying that agile doesn't make sense today. Agile is all about adaptability, after all.

With a little bit of imagination—and a little help from the right tools—it's possible to adapt agile practices to a remote scenario. It's possible to perform remote pair-programming, for instance. The same is true for refactoring. If you're interested in learning more about remote agile, take a look at our guide.
Thanks for reading, and until the next time.

This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.