Scrum vs Extreme Programming: What to choose?

The process of choosing one software development methodology over another can be daunting, whether you are looking at outsourcing software development or even in-house development. No one wants to be in limbo when faced with several agile frameworks where differences are not so pronounced.  It’s easier to just handpick a development methodology that's conspicuous and whose features distinct rather than those whose features are often close.

This is the case with Scrum and Extreme Programming (XP). The two techniques are so aligned that many developers actually struggle to choose between the two. If you walk into an XP team, you'd initially or entirely take it for a Scrum team.  But while the differences between the two are ultra-fine and mostly unspoken of, they come into play in specific circumstances, which is why you can't just write them off.

Choosing between Scrum and Extreme Programming means first understanding how these two methods operate. So let's first take a closer look at each. 

Scrum Framework

Being the most used among Agile techniques, the Scrum framework is a lightweight development technique that capitalizes on development time to produce high-value software. It is typified by sprints (development cycles or stages). While the technique is mostly applied to software development, it is also used in businesses to accomplish projects. 

«It’s the one we most often use if we're going to have a team do an Agile implementation. We'll bring Scrum in first because it has a bit more rigor to it» Erin Randall, principal coach and founder at Ad Meliora Coaching, and a certified Scrum master and professional told US News.

True to the above claims, most companies using Agile techniques employ scrum for its sheer benefits as indicated by the 2020 State of Agile Reports. 

Scrum is founded on three major bedrocks:

1. Transparency. Each member of the team is required to understand the project, facilitated by regular progress updates.
2. Inspection. This happens over the course of the project (after every sprint) as the project manager sends reviews to help give the project the right bearing.
3. Adaptation. The team takes time to adjust the product where needed and align it with the client’s specifications which brings customer satisfaction.

The scrum life cycle in a nutshell

There are various ways to start the Scrum process, based on your team’s self-organization and experience. The technique incorporates 4 main activities: the kickoff, sprint planning meeting, the sprint, and the sprint review meeting.

1. The kickoff

The team comes together to determine the different roles they have for the project, the project objectives, and the project backlog. The team should involve key roles such as the Scrum master, the product owner, and the rest. While the Scrum master takes up the role of a team leader and ensures that all the Scrum values are implemented, the product owner works to come up with high-end and highly productive software.

2. The sprint planning meeting

The sprint planning meeting happens at the beginning of every sprint and involves all the development team members. 

According to the International Journal of Software Engineering & Applications (IJSEA), Vol.10, No.5, September 2019, the meeting focuses on two major activities:

• The team creates a list of project requirements and demands before setting the sprint’s goals
• The team also establishes the project backlog. This happens later in the final sessions of the meeting.

3. The sprint

Once the sprint starts, no changes can be made to the project objectives. The Scrum master also shields the team from any form of external intrusions. The team leverages the set iteration process to improve the product’s functionality. 

Most sprints are jump-started by a short 15-minute session where every team member gives an account of the work they’ve done since the last Scrum and their plans before the start of the next one. They are also required to highlight any obstacles that they might be facing.

3. Sprint review meeting

Scrum plans for sprint review meetings at the end of every sprint. During the session, each team member airs out any challenges they faced or gives suggestions and opinions. The Scrum master also comes up with ways to ensure that the project remains on track.

When to use Scrum

• When you’re faced with a large project and have the leeway of splitting it into smaller bits. This allows for good planning and realistic results after every sprint. However, you may consider traditional project management if the project follows predictable procedures. A good example is when your project comes up every three months. 
• When the Scrum team is able to deliver increments of the value of the product independently. Hence, be sure to get a cross functional team.
• When you have a well-organized set up. In this way, all the developers are involved and are able to perform their roles with a goal.
• Ideally, Scrum works well with many projects and teams. Companies are able to determine the level of skills and knowledge that their software developers have when handling different projects. 

Recommended reading: Agile Ceremonies Explained

Extreme Programming 

Extreme Programming (XP) is an agile software development technique that is focused on improving the quality of software. Just like Scrum, XP is characterized by several development stages and a few checkpoints that allow for the adaptation of the client’s requirements and consequently improve productivity.

The technique is designed to handle the specific needs of software developers handling dynamically changing and vague software requirements. XP teams are spared from ambiguous work using this framework since they disintegrate the project into smaller sections. In that way, they are able to focus the bulk of their efforts on writing quality code. 

At the initial stages of the project, the team creates and works with a highly iterative process to create a simple design (that aligns with the client’s overall requirements for the project) before continuously developing it to fit the client’s specific demands while eliminating unnecessary complexity.

XP Values

XP is founded on a number of key values, including:

1. Simplicity. The team is out to discover the most efficient route. The team comes up with a simple design that’s easy to change and revise throughout the project time. The team strictly works with the current requirements without making any predictions.
2. Communication. This is fundamental since the developers are working as a team. The team members are required to make appropriate and timely communication with the aid of drawing tools such as a whiteboard.
3. Feedback. Through constant feedback, the team can pause for a second and get back on track or determine ways to improve the product going forward.
4. Courage. XP experts define courage as “effective action in the face of fear.” This value is needed throughout the project where a developer can air out issues that they think are faltering the team’s productivity. A courageous developer will try different ways to make a project successful. 
5. Respect. This value makes communication effective and spurs a teamwork spirit. In that way, the team members share the same goal and achieve it.

XP practices

At its core, XP operates under a set of software development practices. These practices work most effectively when they are implemented in totality without exemption. 

Below are the 12 XP practices:

• Whole team. XP incorporates a cross functional group of developers who have different roles in a project. The team involves both the client and the group of developers who work to meet the client’s needs. 
• Sit together. Due to the sheer need for communication between developers, the teams need to sit and work together without any hindrances to communication such as cubicles.
• Energized work. This involves doing anything that will keep you focused and effective at work. Hence, you will need to take action against anything that distracts you or threatens to divert your focus at work. As you remain energized, ensure that you reciprocate the same to other team members.
• Pair programming. This refers to the idea of developing software by two people. This is backed by the fact that two people or two brains are better than one. Two people get to tackle issues effectively and a project that might have left one developer stranded may not be much of a hassle for two developers. 
• Informative workspace. The workspace should be laid out in a manner that facilitates face-to-face communication. However, respect each other’s personal space and allow them some privacy whenever they need it. 
• Stories. These are short descriptions of the project. The team describes what the users are able to do with the product. Hence, their language should be understandable or meaningful to the targeted users.
• Weekly cycle. This is similar to an iteration where the team holds a conference at the start of the week, takes a look at what they’ve accomplished so far, and sets goals for the week viz-a-viz the client’s stories.
• Quarterly cycle. Synonymous to a release, this cycle is important in keeping the weekly cycles on track. The client, therefore, proposes their overall plans and tasks that they need to be completed by the end of a particular quarter. 
• Slack. Ideally, XP teams identify some low-priority stories which they add to their cycles. These stories can be put aside in case the team is faced with high-priority tasks.
• Ten-minute build. This refers to assembling the whole system and conducting a test run in 10 minutes. The 10 minutes were deliberately recommended to ensure that teams conduct the test runs at the end of the cycle without failure. Experts argue that the longer the test runs the less the likelihood of conducting it.
• Continuous integration. This practice is meant to eliminate integration issues as soon as they arise. It involves testing the codes right after they change and are added to a larger code base. While many teams will skip this practice because of the dread of discovering way too many integration issues, XP experts recommend it. 
• Test-first programming. Normally, programming follows this procedure: develop code -> write tests -> run tests path.  However, this XP practice involves: Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat
• Incremental design. This practice allows teams to start by doing light tasks or create a simple design as they understand what they are required of the project. They then take a deep dive into the project after having established what the client requires. This approach reduces the chances of going back and forth or doing unnecessary work.

The verdict: what to choose between Scrum and XP?

First, it’s important to understand the key difference between these two methodologies. The key difference is that while Scrum does not restrict teams on which engineering  practices they should use, XP puts a lot of emphasis on programming procedures and teams are required to follow them strictly. So it’s fair to say that XP is much more technical compared to Scrum. In Scrum, developers have the freedom to make decisions on how to go about the work, as long as they generate the desired value. In XP, the developers are restricted,  the priority plus the order in which features should be developed is outlined by the customer and the team is required to follow this order.  In Scrum, the customer defines the priorities but the team has the freedom to  determine the order they will follow to clear the items in the backlog. 

So which one should you choose? Simple: Choose Scrum for software project management and for those projects that seem to have a lot of unknowns especially at the beginning. Choose  XP for highly technical projects where developers need to follow certain programming procedures from day to day such as automated testing, test-driven development, refactoring and pair programming.

Here is a summary of the key differences between Scrum and XP:

Here is a summary of where both Scrum and XP are best suited for use:

Further reading: Agile Team Roles

Final remarks

As you may have noticed, the differences are very fine. But the impact can be profound. The good news is that you can actually use Scrum and XP together. Just know that if you use the two, then Scrum will be best suited in the overall management of the project while XP will be best suited for the day to day programming tasks. 

The best advice is to start with Scrum as the main methodology, then bring in XP as an additional practice. After al Scrum allows the addition of more practices and so this will be a smooth way to get the two to work together.