Hello great people of the world. Welcome back to Professional Scrum Developer (PSD) blog series with yours truly. It's been a while since my last blog on "Scrum And ...". Alrite, this time I am going to discuss Scrum and eXtreme Programming (XP). I would like to discuss Scrum and XP because I often get a question "When should I use Scrum or XP?" from people in the community. My natural answer to this question is 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 behaviours. We'll see why XP is not only about technical practices in this blog.
In this blog, I will fit XP into Scrum. So in this blog, the perspective I will be using is from 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 valued in XP. Many practices in XP is about feedback. Release planning is about feedback. 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 has the courage to speak the brutal truths, no matter how unpleasant it is. XP teams have the courage to seek for 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 XP coach. Just like the Scrum Master, the XP coach is to coach the team on XP values and principles. But unlike the Scrum Master, XP coach also coaches the development team on technical practices. In 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 beneficial as sometimes the development team expect the Scrum Master to come up with all of the technical solutions. Scrum Team who wants 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 engineer like 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 whole team approach. What that means is, 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 of 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. If 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 mandates the iteration to be only one week long. XP requires the team to work at a sustainable pace, that is 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 one week ahead.
Sprint Planning
Scrum does not mandate the usage of Planning Poker and Story Points. That is 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. Scrum Team is free to choose how they want to estimate. In fact, Scrum team is allowed to estimate in hours if they wish. Scrum Team who is practicing XP will do Planning Poker with Story Points every Sprint Planning. Many Scrum Team found this Planning Poker practice with Story Points is helpful.
Scrum Team who 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 the story points for every story completed during the Sprint is called the velocity. Just like Story Point is not part of Scrum, velocity is also not part of Scrum. During Sprint Review 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 test with the team. For Scrum Team practicing XP, during 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 Team will assess what is possible for the next week Sprint based on what has already been delivered to production
Artefacts
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 Story. Writing the Product Backlog in stories is helpful for the team because stories is 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 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 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, that is why many teams end up with having Architecture story, Technical story, even a Bug story.
Many teams found that User Story is helpful for them. Scrum Team 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 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 about Scrum that I often found in the community because many people think that a Sprint is just a mini-waterfall.
XP requires the increment to be deployed to production daily. So Scrum Team practicing XP will have deployed to production as one criterion in their definition of "Done". Because of this practice, Scrum Team practicing XP is hyper-performant.
Definition of Done
Scrum does not tell us how the definition of done looks like. For some people that is quite confusing. That is why some people even 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, and done 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 decouple 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 is inside 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 Team practicing XP will pair program throughout the Sprint. Yep 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 review. 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 Team practicing XP will put pair programming in the definition of "Done". Pair programming configuration may be two developers working with one machine or a programmer and a tester working together.
Test First Development
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 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 Scrum team. Scrum team strives 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. From Test First Development, the team will discover it is possible to do incremental design. With Test First Development developers will discover that it is actually possible to do 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 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. When the build runs longer than ten minutes, developers will reluctant to continuously integrate their code. When developers are not continuously integrating their code, they will lose feedback. XP highly values feedback, 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 developers code 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 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 it creates a higher bandwidth of communication. Higher bandwidth communication means the team is reducing misinterpretation and increasing shared understanding.
Release Planning
Scrum Team plans 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, Scrum is 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, Scrum Team practicing XP is a hyper-performing team. XP is one of the missing piece Scrum team 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.