Scrum vs Extreme Programming (XP)
 

Scrum vs XP

Both are very similar that are aligned with each other and complement each other.  If you walked to a team then it very is very hard to recognize which practice team is using if they are using one of the above practices.  XP is Scrum with technical practices. It’s mindset/behavior and a more prescriptive approach with a strong feedback loop.

Scrum
XP
The iteration is between 2 to 4 weeks. The iterations are 1-2 weeks or less. For very aggressive teams, it can go up to a day.
In Scrum product owner prioritizes the product backlog but the Scrum team has a privilege to chose a lower priority item in a sprint to work on before the high priority XP teams must always work in priority order as features to be developed are prioritized by the customer.
Changes in the sprint are not allowed XP Teams are much more amenable to change within their iterations, but change can only be made if the team hasn’t started working on a feature and at the same time the change is of the equivalent of the swapped item.
The validation of the software is completed almost at the end of each sprint, (i.e. Sprint Review) The software needs to be validated at all times, to the extent that the tests are written prior to the actual software.
Scrum doesn’t prescribe any engineering practices The XP does.
The Scrum Master is responsible for what is done in the Sprint, including the code that is written A developer can modify or refactor the parts of the code as and when the need arises.

 

The teams start with Scrum and move towards XP. There is lots of focus on Self Organizing teams and XP encourages that to a great extent. The Maturity model that we have prepared for CDK has more focus on Scrum up to level 3 and further, the direction is to adopt XP in order to get on to level 4 and 5.

The original XP is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices as listed below

The Planning Process

The desired features of the software, which are communicated by the customer, are combined with cost estimates provided by the programmers to determine what the most important factors of the software are. This stage is sometimes called the Planning Game.

Small Releases

The software is developed in small stages that are updated frequently, typically every two weeks.

Metaphor

All members on an XP team use common names and descriptions to guide development and communicate on common terms.

Simple Design

The software should include only the code that is necessary to achieve the desired results communicated by the customer at each stage in the process. The emphasis is not on building for future versions of the product.

Test-Driven Development

Testing is done consistently throughout the process. Programmers design the tests first and then write the software to fulfill the requirements of the test. The customer also provides acceptance tests at each stage to ensure the desired results are achieved.

Refactoring

XP programmers improve the design of the software through every stage of development instead of waiting until the end of the development and going back to correct flaws.

Pair Programming

All code is written by a pair of programmers working at the same machine.

Collective Ownership

Every line of code belongs to every programmer working on the project, so there are no issues of proprietary authorship to slow the project down. The code is changed when it needs to be changed without delay.

Continuous Integration

The XP team integrates and builds the software system multiple times per day to keep all the programmers at the same stage of the development process at once.

40-Hour Week

The XP team does not work excessive overtime to ensure that the team remains well-rested, alert, and effective.

On-Site Customer

The XP project is directed by the customer who is available all the time to answer questions, set priorities, and determine the requirements of the project.

Coding Standard

The programmers all write code in the same way. This allows them to work in pairs and to share ownership of the code.