Scrum and eXtreme Programming (XP)

Hello, great people of the world. Welcome back to the Professional Scrum Developer (PSD) blog series with yours truly. It's been a while since my last blog on "Scrum And ...". This time I am going to discuss Scrum and eXtreme Programming (XP). I would like to discuss Scrum and XP because I often get the question, "When should I use Scrum or XP?" from people in the community. My natural answer to this question is that a professional Scrum team will use XP practices. Scrum teams who are religious in doing retrospectives will discover that they need to do XP practices if they want to go full steam in the future Sprints. You may also have heard on the street that "XP is Scrum with technical practices." Well, sort of. XP is not only about technical practices. Just like Scrum, XP is also about mindset and behaviors. We'll see why XP is not only about technical practices in this blog.

In this blog, I will fit XP into Scrum, and I will be using is the Scrum perspective. That means any Scrum elements that are not described here is because either XP does not have it or XP teams are doing it implicitly.

Values

Okay, one of the reasons why XP is not only about technical practices is because just like Scrum, XP is based on values. XP values are Communication, Simplicity, Feedback, Courage, and Respect. Just like Scrum, XP values Courage and Respect.

Feedback

Feedback is highly encouraged in XP, with many practices in XP based on feedback. Release planning is about feedback. The one-week iteration is about feedback. Pair programming and test-first development are about getting live feedback about the code quality. Continuous integration is about getting quick feedback about whether the application is integrated. Daily deployment to production is about feedback whether the code will really work in the real environment that will be used by the customer.

We will see throughout this article how many practices in XP exist because XP teams want to get as many and as frequent feedback as possible.

Courage

Courage is important in XP. Teams using XP have the courage to speak the brutal truths, no matter how unpleasant it is. XP teams have the courage to seek the simplest solution no matter how difficult it may be. XP teams have the courage to be transparent because only from transparency they will get real feedback from the customers.

Respect

Respect is important in XP, too. Just like Scrum, XP values cross-functional teams. XP teams need to respect each other regardless of everyone's background and skills. XP also expect customers and executives to be working together with the team. Customers and executives who respect the team do not use their political power to get their personal agenda. If the customer and the executives don't respect the team, XP will simply not work. Just like Scrum, XP is also driven by a common goal.

Roles

Scrum Master

XP has an informal role called the XP Coach. Just like the Scrum Master, the XP Coach's main priority is to coach the team on XP values and principles, but unlike the Scrum Master, the XP Coach also coaches the development team on technical practices. In the Scrum Guide, we've learned that Scrum does not require the Scrum Master to have technical skills. A Scrum Master with a technical background may be beneficial but from my experience, sometimes it is not as the development team may expect the Scrum Master to come up with all of the technical solutions. Scrum Teams who want to add XP practices may want to hire an external XP Coach to help the development of technical practices until they get used to it. XP doesn't expect the XP Coach to be on the team until the end of the project lifecycle.

Product Owner

The Product Owner is like the Project Manager plus the user in XP who is responsible to communicate the project to the stakeholders and also select which Product Backlog Item will the development team work on first. XP has a role called Product Manager who is responsible to fine tune the user story. At Scrum.org we prefer those who work as requirements engineers like the XP Product Manager to be in the development team rather than be the Product Owner.

Development Team

Scrum does not define the composition of the Development Team. Scrum views everyone in Development Team as Development Team member. Scrum just expects the development team is cross-functional as such they can deliver potentially releasable increment every Sprint.

Just like Scrum, XP values a "whole team" approach. What that means is that all skills that are required to turn the selected stories into a releasable software must be on the team. In, XP interaction designers and technical writers are also part of the XP team. If the software development requires database administration work, then the DBA needs to be on the team. Because XP values real customer involvement, the user is also part of the development team.

Events

Sprint

A Sprint in Scrum is not a release cadence but a planning cadence. Just like Scrum, in XP the iteration (Scrum sprint) is a planning cadence, not a release cadence. However, whereas Scrum allows you to choose the Sprint duration to be in one month or less, XP does not allow the iteration to be more than one week. XP requires the team to work at a sustainable pace, typically 40 hours a week. Scrum Team practicing XP will adjust the number of stories they pick per Sprint as they only work 40 hours per Sprint.

Doing a one-week Sprint is not easy. If you're not using a one-week Sprint, well...you're not using XP because this is the rule. In XP, the duration of the Sprint is not an option. Having a one-week Sprint means the customer will get faster feedback about the progress of software development. Planning a one-week Sprint is much easier as it is much easier to predict what will happen in one week and how the development team will use their time.

Sprint Planning

Scrum does not mandate the usage of Planning Poker and Story Points. That's right, Planning Poker and Story points are actually not part of Scrum. This is the common misconception people have about Scrum that I have found in the community. A Scrum team is free to choose how they want to estimate. In fact, Scrum teams are allowed to estimate in hours if they wish. A Scrum Team practicing XP will do Planning Poker with Story Points every Sprint Planning. Many Scrum Teams found this Planning Poker practice with Story Points is helpful.

The Scrum Team that is practicing XP will select the stories that can be completed in a one-week Sprint. The selected stories have coherence and the connecting dots between the selected stories may be the Sprint Goal for the Scrum Team. During Sprint Planning the Development Team will break these stories into tasks that will be done by the whole Development Team.

Sprint Review

The accumulation of story points for every story completed during the Sprint is called the velocity. Just like Story Points are not part of Scrum, velocity is also not part of Scrum. During Sprint Reviews, the Scrum Team will calculate the velocity. For some teams using velocity is useful to forecast the future development and also to predict how many PBI the team gauge every Sprint Planning.

Scrum Teams practicing XP will have their increment deployed to production daily. While Scrum does not require the customer to be on-site, XP requires the customer on-site and continuously testing with the team. For Scrum Teams practicing XP, during the Sprint Review, the customer, Product Owner, and Development Team will review the product that is already in production. The Sprint Review will not be the first time the Product Owner and the customer has seen the product. Scrum Teams will assess what is possible for the next week Sprint based on what has already been delivered to production.

Artifacts

Product Backlog

Scrum requires the Product Backlog to be transparent as it is the single source of truth for any changes made to the product. XP teams write User Stories instead. Writing the Product Backlog in stories is helpful for the team because stories are from the user perspective. Scrum does not require the Product Backlog Item to be written in User Story. This is another misconception that people have about Scrum; many people think that the User Story is part of Scrum. One of the reasons why people have this misconception is because some tools require the team to write the Product Backlog Item in a User Story format. Another reason is that many Scrum tutorials on the internet relate User Story to Scrum. Because of this misconception, people end up forcing everything to be written in User Story, which leads to many teams having an Architecture Story, a Technical Story, or even a Bug Story.

Many teams found that User Stories are helpful for them. Scrum Teams practicing XP will write some of their Product Backlog items in User Story but some PBI may be written in other formats that make sense to the team.

Sprint Backlog

The Sprint Backlog is user stories selected during Sprint Planning along with the tasks to complete those stories. The Sprint Backlog is a one week's worth of work for the Development Team. Scrum Team may have other tasks that are not related to the selected stories in their Sprint Backlog.

Increment

The common misconception people have about Scrum is that you can only deploy to production after the end of the Sprint. Scrum does not stop people to deploy to production more than once in a Sprint or even more than once in a day. The Sprint Review is not a phase gate or a User Acceptance Test (UAT) session, another misconception I have often found because many people think that a Sprint is just a mini-waterfall.

XP requires the increment to be deployed to production daily, so Scrum Teams practicing XP will have "deployed to production" as one criterion in their definition of "Done." Because of this practice, a Scrum Team practicing XP is hyper-performant.

Definition of Done

Scrum does not tell us what the Definition of Done looks like. For some people that is quite confusing. That is why some people think that the Acceptance Criteria is the definition of "Done." Scrum just tell us that the increment delivered by the development team to be "Done" every Sprint, which only means meeting the Scrum Team's definition of "Done".

Scrum Teams practicing XP will find the XP technical practices to be useful because XP technical practices can be used as a starting point for Scrum team definition of "Done" to increase the quality of the software and to increase agility. So XP technical practices are inside Scrum definition of done. For Scrum team practicing XP, here are XP technical practices that are part of their Definition of Done.

Daily Deployment to Production

Scrum deliberately decouples release to production from the Sprint. Scrum does not say that you cannot release or deploy to production in the middle of the Sprint. A Sprint in Scrum is not a release cadence but a planning cadence. Scrum Team practicing XP must deploy to production daily.

XP teams are religious in deploying the increment to production daily. XP requires daily deployment to production to mitigate risk because the bigger the gap between what's inside the developer's machine and what is in production, the bigger the risk the team will face at the end of the Sprint or at the end of the project. If there are no deployment to production every night, the team will not get fast feedback about how the software they develop works in a real environment that will be used by the customer. XP highly values fast feedback. While many teams will face fear every time they deploy to production, XP teams are very courageous to deploy to production daily.

Pair Programming

Scrum Teams practicing XP will pair program throughout the Sprint. Many managers found that pair programming is expensive but pair programming is more than just two people programming using one computer. Pair programming is a micro-feedback loop. Pair programming is about live code reviews. XP teams want to capture problems or dirtiness in their code earlier by having a live code review. Pair programming is about two people collaborating to solve a problem together because two heads are better than one. Scrum Teams practicing XP will put pair programming in their definition of "Done." Pair programming configurations may be two developers working with one machine or a programmer and a tester working together.

Test-First Development

A Scrum Team practicing XP will write the test code first before they write the production code. Some managers and some developers find this practice is too expensive because developers will write twice or more the amount of code than they should. I will not discuss in detail about test-first development here as that will be another "[PSD series] Scrum And ..." blog content.

Test First Development is a valuable practice for a Scrum team. Scrum teams strive for excellence and great quality product. With Test First Development, people are forced to think about the "What" first before writing the "How." With Test-First Development, developers will get faster feedback about the code. With Test-First Development developers are forced to continuously refactor their code and strive for the simplest design and discover it is possible to do incremental design and emergent architecture.

Ten-Minute Build

One-week Sprint, daily deployment to production, Test-First Development, ... hmmh it seems this XP thing is not really easy to do well.

Another XP practice that the Scrum Team will find valuable is the ten-minute build practice. XP requires the code to be integrated continuously and the build must run for under ten minutes. Yes, you've heard it right: the build must run under ten minutes. That is a non-negotiable rule from XP. When the build runs more than ten minutes, the developers may need to refactor their tests code, and developers are reluctant to continuously integrate their code. When developers are not continuously integrating their code, they will lose feedback. XP highly values feedback, and faster build means faster feedback.

Single Code Base

Because XP requires continuous integration and daily deployment to production, XP requires the team to do trunk-based development. That means all of the code based will be in the trunk. This is quite different to what many teams are practicing right now where each developer codes in their own branches. In XP, code that lives in branches does not live for long. Code that lives in a branch for long will not be integrated more often which leaves integration problem until the end.

Other XP Primary Practices

Informative Workspace

Scrum values transparency. Scrum does not dictate how you make that information transparent for everyone. In fact, Scrum allows you to use digital tools to manage the Product Backlog.

XP requires the team to have an informative workspace so anyone walking into the team room knows the progress of the development. XP teams may display the future work, the work for the next 3 months and the work in the current week on the wall. Scrum Teams practicing XP display their work in a physical board in the middle of the room.

Sit Together

Scrum does not require the whole team to sit together in one big room. Scrum works well for a remote team. The Sprint Retrospectives provides an opportunity for Scrum Team to inspect and adapt how remote teams improve the way they work together as a team.

While Scrum does not require the Scrum Team to sit together in one big room, XP does. XP values feedback and by having the whole team sit together in one space creates a higher bandwidth of communication. Higher bandwidth communication means the team is reducing misinterpretation and increasing shared understanding.

Release Planning

Scrum Teams plan the functionalities they will develop in a Sprint during Sprint Planning. So when does the Scrum Team plans at a high level? Scrum is very focused on what is happening in the Sprint so Scrum does not say anything about planning at a high level. XP teams do quarterly planning or release planning every three months. During release planning, the customer will present what he/she wants to see in the next 3 months and the team will estimate at a high level. The customer uses the release planning to forecast the budget for the 3 months' development. The development team may forecast any skills they require for the next 3 months. Scrum Team practicing XP will find Release Planning practice valuable for them.

Closing

Well, there you go. Scrum and XP. At its core, the difference between Scrum and XP is subtle. Scrum is just a framework for product development, a container where you can add other practices. XP is one of those practices that you can do within Scrum framework. As you can see, there are no reasons why you should choose between Scrum And XP. I must say XP rules and practices are not easy and the majority of XP rules are non-negotiable. Adding XP into Scrum should be the next natural path for teams starting out with Scrum and striving to be a professional Scrum Team. From my experience, a Scrum Team practicing XP is a hyper-performing team. XP is one of the missing pieces Scrum teams need to deliver great quality products. Scrum and XP are well-aligned and complements each other well hence the question of whether to use Scrum or XP are irrelevant.

So hopefully, this blog with the visual helps you understand how to use Scrum and XP together. Looking forward to hearing you exploit Scrum and XP to develop great products. If your Scrum Team has not used XP, let me know the outcome of your team using Scrum and XP. If your team want to learn how to use Scrum and XP check out Professional Scrum Developer course. Cheers.