Extreme Programming vs Scrum: Learning the Differences Between Two Agile Frameworks

Over the decades, there have been a number of different project management methodologies to guide software product development, help it succeed, and meet predefined requirements. The traditional (also known as linear) approaches such as Waterfall include a number of sequential phases that are always executed one after another. However, such methods are often slow, costly, and inflexible. Not to mention that they require a lot of planning and strict control over the development process.

In 2001, a group of 17 software development professionals introduced Manifesto for Agile Software Development where they presented a newer model that was supposed to address the shortcomings found in the traditional methodologies. And well… It coped with this task flawlessly. The Agile project management approach quickly became popular by harnessing such principles as flexibility, work breakdown into short iterations, the value of teamwork, continuous improvements, and close cooperation with a client.

Yet, the whole Agile thing may be confusing since it’s not a single method but an umbrella term for a vast variety of methodologies and techniques. Scrum and Extreme Programming (XP) are the two Agile frameworks that we will spotlight here.

If you’re a newcomer, you may have a lot of questions. Are these approaches competitors? Can you use both? How are they different and similar? Isn’t XP a Windows OS version? Just kidding about the last one, but still…

This post aims at answering these and other questions while shedding some light on the “Extreme Programming vs Scrum” dilemma. So, let’s get to it.

What is Scrum?

According to the 15th Annual State of Agile Report, Scrum is the most widely used Agile framework with 66 percent of companies who took part in the survey identifying it as the methodology they follow most closely. An additional 15 percent of respondents follow various derivations of Scrum such as Scrumban (9 percent) and Scrum/XP (6 percent).

Just like many other methodologies that belong to the Agile family, Scrum is based on short iterations called Sprints. Each Sprint lasts from 1 to 4 weeks.

What differentiates Scrum is that it prioritizes customer participation early in the development cycle. Also, testing should be conducted as early as possible and as often as possible: It is performed at every point when a stable product version becomes available.

Scrum framework lifecycle

Okay, but how does Scrum work? To understand that we need to deal with the team and roles first.

Scrum team and roles

Scrum isn’t only about software. Its main focus is on people and the ways they cooperate to bring the most value. In this method, all the work is done and shared between the Product Owner, Scrum Master, and the Team. They all create… well… the Scrum Team 😀

The Product Owner communicates with executives, customers, users, stakeholders, and the team to create a product backlog (list of product requirements ordered by priority) and draw the complete picture of the product. Simply put, this person takes the responsibilities of the product manager.

The Scrum Master is responsible for ensuring the team follows the Scrum framework and aligns its actions with the set principles. They also approve the number of team members and their responsibilities. The Scrum Master contributes to the end sprint goals.

The Scrum Team also includes developers who implement planned Sprints and turn a selection of the work into an increment of value during each iteration. The Team also communicates with stakeholders to inspect the results and make adjustments for the next Sprint.

If you look at the viz above, you’ll see where each Scrum team member sits and what they do.

Scrum artifacts and meetings

The Scrum model uses three primary artifacts (development documents) — Product backlog, Sprint backlog, and Sprint burndown chart. They are created by the team and used to manage the requirements and track the project's success.

Product backlog contains software requirements that can be documented in the format of user stories or something else. It is updated with new requirement items regularly.

Sprint backlog lists the requirements from the product backlog that the team committed to complete by the end of a certain Sprint.

Sprint burndown chart tracks the progress and shows the number of planned items to be done during a day and those actually completed. One of the main Agile metrics, the chart enables team members to be more accurate in forecasting their results as compared to initial schedule estimates.

The entire Scrum process is executed through a number of regular meetings and events. The most common set of meetings includes Sprint planning, daily Scrum, Sprint review, and Sprint retrospective.

Sprint planning is the starting point when everyone involved in the project including a Product Owner, a Scrum Master, and a Development Team decides on the amount of work to be done, people responsible for bits of work, and ways to accomplish everything. If it's a one-month Sprint, the planning stage takes about eight hours. Shorter Sprints take less time respectively.

Daily Scrum meetings are 15-minute events held at the beginning of each day when all team members discuss their progress, map out what should be done that day, and make adjustments when necessary.

Sprint review is the meeting held at the end of each Sprint. Its aim is to show the stakeholders the results of completed work and collaborate on the next steps. Sprint reviews ordinarily take four hours for a one-month Sprint.

Sprint retrospective is a wrap-up meeting that takes place at the end of Sprint. During this event, the team takes a look at what went well and what went wrong, elaborates on what can be improved, and places the next round of Sprint product requirements.

Short iterations allow for better flexibility as features can be prioritized and adjusted timely with feedback. But Scrum doesn’t put focus on the technical side of software development unlike Extreme Programming.

What is Extreme Programming?

Introduced in 1990 and documented in the book Extreme Programming Explained: Embrace Change in 1999 by Kent Beck, Extreme Programming (XP) is a set of practices applied to software engineering to improve code quality and the ability to adapt to changing requirements. The key feature of the approach is the emphasis on technical aspects of software development. This distinguishes XP from the other approaches.

Extreme programming lifecycle

Unlike Scrum, XP is less frequently adopted as a standalone methodology with only 1 percent of companies identifying it as the approach they follow most closely. At the same time, the low-risk and predictable nature of XP makes it a good choice for risky or new projects where a customer sets strict requirements and deadlines. Besides, the unmixed XP works well for small teams that don’t exceed 12 people. That’s why this 1 percent exists.

There are commonly 4 key phases of the development process that iterate continuously.

Planning — the team decides on the requirements in the form of user stories, estimates these stories, and maps out a release plan (if user stories can’t be estimated, the team uses so-called spikes meaning there’s more research that should be done).

Coding — the developers actually write code and apply the key XP practices such as pair programming, continuous integration and delivery (CI/CD), and collective code ownership.

Testing — automated testing and customer testing are performed to identify whether a product meets the requirements.

Listening — all the members communicate to provide feedback, with customers and project managers involved.

XP team and roles

All of the above-mentioned phases are secured by the communication and cooperation of XP team participants, each having their own responsibilities. The main roles in the XP team are:

• customers who create user stories, provide feedback, and make business decisions related to the project;

• programmers who implement user stories and write code;

• testers who are responsible for conducting unit tests;

• project managers who serve as an intermediate between developers and customers; and

• coaches who can be included in the team to provide guidance and understanding of XP practices.

The XP team is supposed to follow the core values of the framework such as communication, simplicity, feedback, respect, and courage.

XP practices

One of the main features that sets Extreme Programming apart from other methodologies is that it emphasizes strong engineering practices.

Small Releases. In XP, each release version should be as small as possible. Of course, the precondition is that each version has enough value for the release. Since smaller releases are implemented more frequently, customers can understand the progress of the project in real time and provide more input for next iteration planning.

Planning Game. The basic idea behind the planning game is to quickly develop a plan and then gradually refine it as the details of the project become clearer. The plan includes the upcoming iterations and releases with tasks assigned to each member.

On-site Customer. To ensure that development results are close to customer expectations, the XP methodology needs the full participation of the end customer throughout the development lifecycle.

Simple design. This practice seems easy to grasp but it's often misunderstood. Many critics accuse XP of neglecting good design. In fact, the XP practice doesn’t ignore the design but rather suggests making it the simplest one that works.

Pair programming. This practice requires two programmers to work side by side on the same code. The first developer may focus on writing the code, while the other one can review it, suggest improvements, and fix mistakes.

Test-driven development (TDD). Since XP relies on short development cycles, it allows for receiving frequent feedback that comes from testing. The TDD technique entails writing automated unit tests before the code which helps avoid a significant number of feedback loops.

Refactoring. This technique improves code and makes it cleaner and more elegant by removing redundancy and unnecessary functions.

Continuous Integration. The XP team commits code integration and delivery multiple times to ensure the system works as planned. Parts of code can be reused and reshared. To eliminate any integration issues, the team uses the policy of shared code. Bugs caused by refactoring and code co-ownership can be identified and fixed early. After one commit, everyone else is responsible for integrating the code.

Collective code ownership. The responsibility for the design of the system lies on the whole team's shoulders. No programmer is solely responsible for a particular module or technology, and each member can participate in the development and propose new ideas.

Code standards. The XP methodology implies that there should be common code standards (same formats and styles for code writing). This prevents teams from arguing over some details as they are on the same page.

System metaphor. It is the initial, global view that ties the whole system together. The metaphor is a simple design with individual modules that are obvious and intuitive. If the appearance of a module doesn't match the entire metaphor, then you know the module is wrong.

40-hour week. The XP methodology suggests that working overtime will eventually stifle team enthusiasm and lead to project failure. The 40-hour-week practice is the best way for the team to keep the work-life balance and perform well without burnout. In XP, the project is seen as a marathon, not a full-speed sprint.

Differences between Scrum and XP

As you may have noticed, the two Agile methodologies described above have a lot in common: They both rely on iterative work, continuous development and integration, and communication with a customer. But there are quite a few differences between XP and Scrum.

Scrum vs XP comparison

Focus: The main difference that lies on the surface is Scrum focuses on the process and self-organization while XP focuses on practice.

Iteration time: Both Scrum and XP teams work iteratively, but the Scrum cycle typically lasts for 1-4 weeks, while the XP cycle is shorter — 1-2 weeks.

Change acceptance: The Scrum team does not accept any changes within the Sprint. XP, on the other hand, is more flexible about changes. If the new user story is similar in size, for example, it can replace the old one.

Decision-making independence: The XP team works strictly according to the order of feature development determined by the customer. When it comes to Scrum, the self-organized teams decide on which features to work on first.

Engineering practices: Scrum doesn't define any engineering practices. It just provides you with generic, operational aspects to follow. But XP introduces engineering practices aimed at helping developers write clear code such as automated testing, pair programming, simple design, refactoring, etc.

To sum up, Scrum and XP aren’t competitors. That’s why many organizations prefer using them in tandem. Often it looks like this: Scrum is used at the project management level and XP when it comes to the engineering practices developers rely on in their day-to-day work.