Core differences between XP and Scrum

Definition of extreme programming (XP)

The "extreme" in extreme programming refers to applying the principles and practices we agree on to effectively develop software to the limit, and practice it frequently, such as: "If unit testing is important, then we do test-driven development. If integration Testing is important, so there are multiple integrations in a day and repeated regression testing.” Pair programming is more of an emphasis on "if the code review is good, then we keep doing code review", so we do pair programming. Pair programming is when two people use the same computer to complete the same task, with one person doing the coding and the other reviewing the code, so that code reviews can be performed all the time.

Where XP fits in agile

Image Source:NOKIA 

Let's put Lean aside first, this one is not what we are going to discuss today. In fact, the lean production methods that originated in Toyota have had a huge impact on agility. As can be seen from the inclusion relationship in the figure, both Scrum and XP are a kind of agile methods. They have many intersections, but they are more different. Both occupy a very important position in agile methods.

Can you be agile with Scrum?

Yes, but not enough. Let's start by reviewing what agile is, and I like to use this phrase to explain agile: the continuous delivery of the product that is most valuable to the user. No matter how you define agile, it must be inseparable from "frequent delivery in short cycles". A key question for everyone to think about: When product lead times are shortened from months to 1-2 weeks, and even further to days, how should practices related to configuration management and quality assurance be upgraded to cope with such frequent deliveries? This is a real and acute problem that we cannot do with Scrum alone. As long as the three major meetings of Planning, Review, and Retro are held every two weeks and the Daily Scrum is held every day, as long as user stories are recorded and tracked in the form of cards, and as long as the iteration scope and progress are presented in the form of burndown charts, whether Can we claim that we are already "agile"? The answer is of course no. This is just to soothe our mood, of course, it does attract a booming business for Scrum, because the cost of Scrum introduction is really low. In Scrum, we do not mention configuration management (CI/CD) and quality assurance (TDD), automated testing, etc. Because of this, Scrum has a low threshold and everyone can adopt it, which caters to the needs of many teams, and can make the process more regular and achieve some results. But if you really want to do it well, the practice of technical aspects must be inevitable. In the entire agile implementation process, continuous delivery is the most difficult and requires certain technical improvements, not just processes. More and more organizations, despite the introduction of certain agile processes, methods and tools (such as Scrum), claiming to be "agile", are still finding themselves mired in poor code quality, software defects, tests that can't keep up, Severe rework and slow progress made everyone suspicious of agility.

The core difference between XP and Scrum

Simply put, XP is more about technology and engineering practices, while Scrum is more about teamwork and management practices. This is the core difference between the two that I summed up, which is actually very easy to understand. Extreme Programming is one of the most effective of the first agile development methods. Of the various agile methodologies, Extreme Programming places the most emphasis on engineering practices. The specific implementation practices of test-driven development, continuous integration, and user stories at the core of Extreme Programming provide R&D teams with clear and effective guidance, enabling them to keep the software in a workable and deliverable state at any time, enabling iterative delivery of high-quality software become possible. So we can say that without TDD, agile without continuous integration is only a formality, not real agile. The rules of Extreme Programming are very simple. Using Extreme Programming is like playing a jigsaw puzzle. You will see a lot of small pieces of the puzzle. Each piece alone seems meaningless, but when combined, you will see a complete picture. These rules may appear childish and clumsy at first glance, but they are backed by solid values and principles.

XP rules

• Plan：Write user stories. Develop a release schedule based on the release plan. Do frequent small releases. Break the project down into iterations. Drive each iteration with an iteration plan.

• Manage：Provide a dedicated and open office space for the team. Sustainable rhythm. Start each day with a stand-up meeting. Team development speed is measurable. Have the team sit together. Adjust flawed rules.

• Design：Simple principle. Set up a system metaphor. Use CRC cards in design communications. Use the Spike method to reduce risk. Don't over-engineer or add unnecessary functionality prematurely. Refactor the code as much as possible.

• Programming：Clients are closely involved in teamwork. Follow coding conventions. Write tests first. Build production code with pair programming. Only one pair of programmers can integrate code at a time. Continuous integration. Pick a machine dedicated to code integration. Code collectively owned.

• Test：All code must have unit tests. All unit tests must be run through before release. Find a bug and add a unit test. Acceptance tests are performed regularly and test results are published.

Relationship between XP Rules

Readmore:

1）【A Brief History of Agile】Jeff Sutherland - Doing Twice the Work in Half the Time

2）What Are The Complete Scrum Artifacts?