How can I combine technical practices of extreme programming (XP) with Scrum?
Despite the early popularity of extreme programming (XP) over recent years, it has waned. However, many of the practices within extreme programming are still relevant in modern software engineering. The scrum framework is now the most widely used and popular approach to Agile software development globally. Yet, it describes no technical practices beyond the need for a done increment every sprint as agreed in the definition of done.
Both Scrum and extreme programming approach software developments in a similar way, choosing a small amount of backlog and building it in a time box called either a Sprint or iteration. Indeed, the extreme programming approach was influenced by the early work of Jeff Sutherland’s and Ken Schwaber’s 1995 OOPSLA paper introducing Scrum.
Therefore, it makes complete sense that many of the technical practices within XP would be completely compatible with scrum teams. The desire by the founders of Scrum to keep it lightweight and relevant beyond software means that they are unlikely to ever prescribe any individual technical practice. Instead, they define the development team role as being accountable for the quality of the product and allowing them to choose the technical approaches to achieve it.
XP Practises
Several of the extreme programming practices are already implied within Scrum. Scrum masters are taught about the virtues of a sustainable pace, highlighting that scrum teams should be in it for the long term rather than short-term delivery goals. Maintaining a sustainable pace through a Scrum team means that they can operate as a marathon of sprints rather than a single sprint and then burn out. The development team within Scrum is collectively accountable for delivering the sprint goal and creating a done increment. This is very similar to the concept of the whole team within the extreme programming framework.
Scrum starts every sprint with sprint planning, which is half of what is described as the planning game in extreme programming. The second part of the planning game adds in the concept of release planning which looks at near term releases of the product and when they can be delivered.
Shared understanding
An excellent place to start adding in extreme programming practises would be those that support a shared understanding. A coding standard that contains an agreed set of rules that the development team works towards will improve standards and reduce the likelihood of defects within the product. This can be combined with the concept of collective code ownership where no one individual owns the code and the entire code is owned by the whole team. When a member of the team sees poor-quality code, they should fix it immediately.
As software products develop, they become more complex and more challenging to maintain, taking the approach of simple is best and adopting the practice of simple design. Whenever a new piece of code is written, the developers should look for a way to simplify it. A technical approach that helps achieve a simple design is known as refactoring. Additionally, ensuring everybody understands how the system works will enable the whole team to work effectively. The system metaphor allows customers and developers to share the same vocabulary on how the system should work.
Fine-scale feedback
One of the best ways to improve software quality and productivity is the adoption of pair programming. This is the practice of two members of the development team working together to build the solution for the same user story. The additional benefits of pair programming are that knowledge of the system is shared across multiple members of the development team and provides growth and mastery for them too.
Additional productivity and quality gains can be made through the adoption of test-driven development. Test-driven development is a concise cycle in which a test is written; then the code is implemented to make the test pass. Test-driven development ensures that all code has a test, and no superfluous code is written.
Continuous process
With multiple development team members working on the same code at the same time, and the need to create a done increment, the addition of continuous integration is a vital tool. Continuous integration allows the development team to check in small fragments of code along with their passing unit tests to the main branch in the code repository frequently. The build system continuously monitors for changes, and then checks that the integrated system compiles and the automated tests pass. Providing quick feedback to the development team.
Scrum is a framework for maximising the value of a product. Value is only achieved when the product is released and is used by customers. The longer development takes, the longer it takes for value to be realised. The extreme programming practice of small releases reminds the scrum team that they should be releasing their product frequently. Indeed, the scrum framework thrives upon the empirical approach of inspecting and adapting. If the scrum team does not release software for several months, then there is no customer feedback to inspect, and no adaptations to the plan can be made.
How to get started
There are many ways to get started adopting the extreme programming practices within your scrum team. Here are three practical options:
Adopt the test-driven development approach and start writing your tests first.
Find a buddy within the development team and have your first pair programming session.
Review these practices in your next retrospective with the whole team and identify a change to add to your sprint backlog.