Hello everyone. Welcome back to the next 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 this time because I often get a question “When should I use Scrum or XP?”. I would say professional Scrum team will use XP practices. You may also have heard on the street that “XP is Scrum with technical practices”. Well sort of. 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 is 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.
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 is important too in XP. 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. If the customer and the executives don’t respect the team, XP will not work. 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 be technical. 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 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 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 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. In XP interaction designers and technical writers as part of the XP team. Because XP values real customer involvement, the user is also part of the team. Scrum team practicing XP will involve the customer to be part of the development team.
Events
Sprint
XP mandates the iteration (Scrum sprint) to be only one week long. So Scrum Team practicing XP will have a one week Sprint. If you’re not using a one week Sprint, well … you’re not using XP because this is the rule.
Sprint Planning
Scrum does not mandate Planning Poker and Story Points. 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 practice is helpful but Scrum Team is free to use other estimation techniques during Sprint Planning.
Scrum Team who is practicing XP will select the stories that can be completed in one week Sprint. The selected stories have coherence and these connecting dots between stories is 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. Scrum Team implementing XP will have a different taste of Sprint Review because XP requires the team to deploy to production daily. The Sprint Review will not be the first time the Product Owner have seen the product. Scrum Team will assess what is possible for the next week Sprint based on what has been delivered to production
Artifacts
Product Backlog
XP teams write User Story. Scrum does not require the Product Backlog Item to be in User Story. This is another misconception that people have about Scrum, many people think that User Story is a must in Scrum. One of the reasons why people have this misconception is because some tools requires 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 people have Architecture story, Technical story, even Bug story. 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.
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.
Definition of Done
Scrum does not say how the definition of done looks like. Scrum just say that the increment delivered by the team to be done, and done means meeting the definition of done. Scrum Teams practicing XP will find the XP practices useful and can be used as a starting point for their definition of done. So XP technical practices are inside Scrum definition of done. Here are XP practices that are part of Scrum team Definition of Done.
Daily Deployment to Production
Scrum deliberately decoupled releasing from the Sprint. Scrum does not say that you cannot release in the middle of the Sprint. Scrum Team practicing XP must deploy 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 have. If there are no deployment to production every night, the team will not get fast feedback. XP highly values fast feedback.
Pair Programming
Scrum Team 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. Pair programming is about live code review. XP teams want to capture problems earlier. Pair programming is about two people collaborating to solve a problem together because two heads are better than one. Scrum Team practicing pair programming will put pair programming in the Scrum Team definition of done. Pair programming configuration may be two developers on one machine or a programmer and a tester doing it together.
Test First Development
Scrum Team practicing XP will write the test first before they write the production code. Some managers and some developers find this practice is too expensive. I will not discuss in detail about test-first development here as that will be another blog content. Test First Development is a valuable practice for Scrum team. 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.
Ten-minute build
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. When the build runs longer than that, developers will reluctant to continuously integrate their code. 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. 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.
Closing
Scrum is a container where you can add other practices. Adding XP into Scrum should be the next natural path for Scrum Team. Scrum and XP are well aligned and complements each other well hence questions on whether to use Scrum or XP are irrelevant. 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.