Scrum contains a set of practices distinct from XP that are intended to enhance project safety. The Scrum framework is simple and intentionally incomplete. Scrum expects that teams will add in practices that are relevant to their specific context. For example, there is wide recognition within the Scrum community that XP engineering practices need to be added to Scrum to create sustainable software projects. So, Scrum and XP together is a good starting point.
XP = Scrum + Engineering Practices?
I used to think Scrum was contained in XP. After all, XP is a very complete system and seemingly covers most agile concepts. I've since discovered that just isn't true. Now I fully appreciate that there is a valuable set of practices in Scrum that are not part of XP. The remainder of this article will review these five of these practices and how they create a safety net that XP cannot when used on its own.
Figure 1. Scrum contains valuable practices that lie outside XP.
Safety #1: Scrum Has an Outward Focus
Scrum is about delivering something of value in a timebox. It is very simple and very powerful. XP, on the other hand, is complex and very much focused on developer practices. Think of the name - eXtreme Programming. It's about programming. It's about software developers. There are many other important roles in software delivery. Scrum helps bring a more balanced view.
I have seen XP teams doing amazing things on the technical side (TDD, pairing, evolutionary design) and yet miss the bigger picture of customer value. Scrum puts that front and centre.
Safety #2: Product Owner Role
The Product Owner is responsible for working with stakeholders to prioritize project work (via the product backlog) to guide the delivery of business value. This is a clear role with clear responsibilities. The XP notion of Customer or Customer team includes the Product Owner, domain experts, business analysts, stakeholders, and users. The PO role introduces safety and clarity. I even see the term spreading to non-Scrum processes.
Safety #3: Sprint Retrospective
Retrospectives are arguably the single most important agile practice. Scrum makes this the heart of change. Crystal Clear also identifies it in as an essential practice. In the place of the retrospective, XP has the value of feedback. Even as late as 2005, Jim Shore commented that retrospectives are not a standard part of XP. Retrospectives are, however, included in Shore's The Art of Agile Development, which I consider to be the best book on XP available and recommend you get a copy. So, in conclusion, it is clear that, because retrospectives are a core component of the Scrum framework, Scrum provides additional safety and learning in comparison with even Beck's most recent Extreme Programming Explained.
Safety #4: Notion of "Done" and Sprint Review
Scrum requires a definition of "done" for sprint outputs. This allows organizations to identify what is of value to them. XP is focused very much on working software at the detriment of non-software deliverables, such as end user documentation and other artifacts that allow teams to function in larger organizations. Through the explicit notion of done and the sprint review, there is a mechanism for reviewing all work products and verifying that the project is on track. XP has the notion of a demo which is valuable but narrower in scope and does not provide a wider lens to view a team’s work.
Safety #5: Whole Team
In Scrum, the whole team is responsible for defining and delivering work. There is collective responsibility for figuring out how to deliver business value. In contrast, XP places the burden of writing stories on the Customer. In the case of complex problem domains it may take domain experts, testers, and developers to direct the course of the project and figure out what needs to be done. For example, when I recovered an XP team working on mobile navigation software, specifying correct behavior required everyone's involvement. Another dimension to this is that Scrum encourages the development of generalists to balance work and reduce bottlenecks since the whole team is responsible for the sprint commitment. This notion of shared responsibility also drives team dynamics.
Start with Scrum or XP?
Scrum is a safer starting place than XP for the reasons outlined above. There is also a clear evolution path from "Anemic Scrum" to add in the XP engineering practices that are needed for sustainable development.
Starting from XP is more problematic. XP is such a complete set of practices that there is no clear path for adding in Scrum concepts that enhance project safety.
Depending on your context, Kanban may be a good starting place as well. For example, support teams, production lines with standardized work, or large teams with limited specialists might benefit from Kanban.
On the other hand, if you are working with a great coach, you can start anywhere.
(Thanks to Michael De La Maza and Yehoram Shenhar for contributions)