Combining Scrum with Extreme Programming (EP)

Scrum and XP both reside under the Agile umbrella, and although there are some differences between them, they can still work well together. Scrum focuses more on management and organizational practices that impact everyone (senior management, customers, development process, etc.), while XP focuses on more practical aspects of the development life cycle.

I am not saying it’s easy to create such a combination, and the chances are not all your teams will adopt all XP practices. However, combining these methods increases the overall effectiveness of the development process and increases overall development quality. This article will review the core values and practices related to XP and let you decide how to combine them.

A Short History of XP

XP was developed by Kent Beck and introduced in his first book Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999). It was one of the earliest Agile methodologies and the first to challenge the traditional Waterfall model. XP is designed to support small/medium software development teams, and it’s called “Extreme Programming” because it uses twelve proven software development principles and practices and pushes them to extreme levels.

Values of Extreme Programming

Before we dive into the practices, let us first review the values.

Simplicity – Team members will focus on delivering value to the customer fast as possible (“Do the simplest thing that could work”), which means they will not waste time on a complicated design that will likely hold them back from delivering sooner.

“XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it than to do a more complicated thing today that may never be used anyway.” -Kent Beck
Communication and collaboration – Face-to-face communication is a major aspect of XP; communication between the team and the customer and within the team (All team members should work together to complete each task.) is crucial for reducing miscommunication pitfalls.

Courage – The team should have the courage to make fast decisions, which comes from a sense of collective ownership. The two classic examples are:

• The courage to make real changes in software design and architecture when needed.
• The courage to tell the truth about the effort they need to complete tasks (time estimations, implementation effort, etc.).

Feedback – Extreme programming embraces Feedback as a great way to evaluate the current state of the development process.

Respect – Respect the other team members, respect the customer, and respect the business.

The Core Practices and Principles of Extreme Programming

Principle 1: The planning game

The main planning process within XP is called the planning game. The game represents a meeting occurring once per sprint. During this meeting, the team decides the scope of the next release that meets customer requirements based on priorities and technical estimations. (In Scrum, we have the planning meeting that uses the same idea created in XP).

Principle 2: Small releases

The main target is to release working and tested software as early as possible, with the smallest useful set of features that increase the business value. Software updates are often developed to support fast releases, and the customer can use this software in their environment involving real users. This allows the customer to evaluate the software and send their feedback.

The main points are:

• The delivered system should be a working system that meets customer expectations.
• The developed system must be achievable in short cycles.
• The system should be delivered in the minimum time necessary to produce it.

Principle 3: System metaphor

The best way to explain this is by following the description given by Kent Beck in his book (Extreme Programming Explained, p. 179):
“The system metaphor is a story that everyone – customers, programmers, and managers – can tell about how the system works.”

Principle 4: Simple design

Albert Einstein once said: “if you can’t explain it simply, you don’t understand it well enough.” This explains why the best design is the easiest one that could work. In XP, we strive to achieve the simplest design that could probably work that meet the business value at any given time, while any complex code design is removed as soon as it is discovered.

Key advantages:

• Helps to keep the team on track.
• Less time wasted on adding complex functionality that does not add real value.
• Fewer logical design failures are more likely in complex code design.
• Makes it easy for each team member to understand what is going on and what they should do.

In Scrum, like in XP, there is a less upfront design than traditional software development methodologies. This means we want to plan only what we can achieve shortly (something like 4-6 sprints). To support this approach, we must keep the design as simple as possible from the start. Continuously improving it throughout the project after that, rather than creating a large complex design that the team will likely fail to implement.

Principle 5: Continuous testing

In XP, each functionality should be covered by a set of unit tests, which must pass for development to continue. The team can use other methods to implement this approach, such as TDD (Test-Driven Development), where the tests are written first, and the code is added and tested afterward.

Continuous testing is very important because it allows the team to reduce technical debt, verify the quality of new code and add automated tests that ensure the system can accept new code without affecting other components.

Key aspects of this concept:

• Testing is done throughout the entire process.
• All tests must run and pass at 100% before new development.
• A new code must be covered with dedicated tests before adding it to CI.

Principle 6: Refactoring

Communication among team members is one of the main values of extreme programming and is crucial when writing code. Each team member must understand how the application should work according to the preliminary design. In addition, he needs to review and update the code to align it to new design and optimization.

The main keys are:

• During the refactoring phase, programmers can edit the current code (as long as it does not affect the functionality), improve software design and remove any code duplication.
• The development team must build the software based on simple and effective design to achieve value per sprint.
• Refactoring cannot be done without corresponding testing to ensure that nothing was broken.
• Refactoring is a continuous design improvement that developers can do at any time.

Principle 7: Pair programming

In pair programming, programmers work in pairs, which means that all code is written by two programmers (the pair) working together on one machine. With pair programming, we can expect higher quality code at the same or less cost as we have in the traditional development model. In pair programming, we have two roles for each pair: the first developer (the one with the keyboard and the mouse) writes and implements the code, while the second developer watches the implementation, identifies any code errors, thinks about code strategies or ways of simplifying it, etc.
You can combine pair programming in any Scrum team, based on my experience, with good results. In the last few years, I have seen more and more teams that I coach coming with an open mind to try this method in their day-to-day activities. The things I have learned so far about pair programming:

• Pair programming improves team knowledge.
• Programmers will gain confidence in their code.
• Pair programming improves team focus.
• Pair programming improves code quality.
• Pair programming works even better when frequently changing partners.
• Pair programming can be exhausting and should not be the primary development technique.

Most often, you will find developers that aren’t comfortable with this approach, do not try to push them to use it (it will not work). Although pair programming is about coding, I discovered that other pairs could work great together, such as two testers or developer and tester pairs.

Principle 8: Continuous integration

We can expect to create software builds several times a day using XP. This allows the team to keep the application up to date with its members’ most recent coding changes. We can ensure stable builds using a CI system, as each part of the code is integrated and tested by dedicated testing suites. These help to remove any hidden bugs that can trigger corrupted builds. In addition, CI systems provide a quick insight into problems at earlier build phases, where the costs are low. It lets the team know where the problem is and who should fix the failed tests. It also ensures quality standards are maintained.

Principle 9: Collective ownership

In XP, the whole team is responsible for the software they develop. No one person owns a specific part of the code (not everyone should know every part of the code equally, although every team member should understand every part).

Advantages and guidelines:

• It is easier to replace team members if someone is leaving.
• No specific developer is responsible for a specific component.
• Any developer can change the code without delay.
• The entire team reviews new code.
• Increases the responsibility of developers.
• Promotes the developers to take responsibility for the system as a whole rather than as parts of the system.

Principle 10: On-site customer

One of the most important concepts of XP is to have an on-site customer that is an integral part of the team throughout the development process. As part of the team, the customer should be available to answer questions, set priorities, set timelines, and establish requirements.

Principle 11: The 40-hour week

If XP practices are effective, the team should be highly knowledgeable, experienced, and dedicated to their work. However, we cannot ask them to be on top of their game if we push them to the limit while demanding 60-70 hours a week. More work hours will only lead to a tired, frustrated, and less effective team that will provide lower quality code with more room for failure.

To overcome this issue, extreme programming emphasizes a limited number of work hours during the week that does not exceed 40-45 hours. If any team member exceeds this limit, we see these hours as overtime, which is limited to only one day a week.

Key guidelines and benefits:

The project shouldn’t interfere with the developer’s personal life.

• The workweek should be no more than 40 hours.
• Consecutive overtime hours will indicate that there is something wrong with the process.
• Senior management should find new ways to allow the team to work fewer hours with more productivity.
• The team will go home on time; there is no reason to do overtime.

In Scrum, we should trust our teams to perform their job without extending overtime. Great teams should be able to achieve the sprint commitments without working more hours than initially planned.

More hours do not mean that the team will deliver a high-quality release. In one case, I had a team working an insane number of hours that were not part of their initial capacity. The quality of their deliverables was very poor, and they had to waste the next sprint’s refactoring.

This is just one example of why long work hours are negative. They represent many pitfalls such as wrong estimations, commitments, etc. After coaching hundreds of Agile teams, I conclude that keeping the team working at normal hours (unless there are explicit and unexpected issues that may occur during a project) helps to improve team motivation and increases their ability to deliver high-quality code.

Principle 12: Coding standards

All team members should write code following the same guidelines, principles, and coding standards (code, documentation, design patterns, etc.). By doing so, we help the team remove any bottlenecks related to unreadable code that may lead to unpredictable mistakes, resulting in unwanted errors and an increase in technical debt.

By following these guidelines, the team will have the power to communicate through the code, which is highly important in XP as each team member can modify the code constantly throughout the day.

Coding standards are a decisive part of XP and Scrum. Coding standards should be part of any project. My experience suggests that a definition of coding standards at the beginning of the project will help the team achieve better results. And the best thing? Defining coding standards will take you no time; make sure you define the basic guidelines agreed upon with the team and improve them as the project goes on.

For example:

• Make sure that your code is more efficient than the original code.
• Ensure that there are no code duplications.
• All exceptions should be self-explanatory.
• The code should be clear and documented.
• Keep the code as simple as possible.
• No new code was added to the CI system without the relevant tests.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile