5 Ways Scrum Creates Safety: Why One CSC Uses Scrum and XP Together to Avoid XP Risks

Five reasons why one CSC chose Scrum for safety and XP for engineering practices

22 February 2011

Michael Sahota
Agilitrix

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)
 




Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Lowell Lindstrom, CST,CSP,CSM,CSPO, 2/24/2011 3:55:32 PM
Hi Michael-

By framing these practices as Scrum or XP, you are describing semantic subtleties. Whether something is XP or Scrum is irrelevant and largely in the eye of the beholder. There never was a single standard definition of XP. There are different snapshot definitions capturing the evolution of XP. These are archived in various books and blogs, but it evolves with each iteration. Scrum does the same in practice, but the community has held to a more precise definition of the framework, for better and worse.

You describe 5 valuable practices that everyone should be familiar with (and practicing, IMO). What tribe one learns them from is really not that important.

Lowell
Michael Sahota, CSC,CSP,CSM, 2/25/2011 6:19:30 AM
Hi Lowell, thank you for sharing. I agree with you that it does not matter where practices come from. I am a big fan of XP and I have observed that the differences are more than semantics. Based on real-world experiences with challenged XP teams I noticed that the Scrum lens can add clarity and safety. Of course, it has some challenge areas relative to XP (but that's another post).
Sree Peyyety, CSM, 3/15/2011 1:56:02 PM
Can you explain what XP is all about?
The only thing that I do see is the pair programming.
Inspect and correction are there in both models.
Michael Sahota, CSC,CSP,CSM, 3/17/2011 12:13:30 PM
Sree, if you are interested in understanding Agile software development, then I strongly suggest you read about XP (e.g. book by James Shore mentioned above). A naive view is the XP = Scrum + technical practices. It is much richer and contributes a valuable perspective that enhances Scrum.
Adam Sroka, CSM,CSD, 3/21/2011 7:42:24 PM
#1 -- XP has even more customer focus than Scrum. XP asks that you actually talk to your customer whereas Scrum suggests that you use the PO as a proxy.

#2 -- The product owner role is obviated by the direct relationship with the customer, though some XP teams adopted a "customer proxy" which is entirely analogous to the PO. Most XP folks see the customer proxy (where needed) as a compromise whereas Scrum sees the PO as an advantage.

#3 -- Retrospectives have always been part of XP.

#4 -- XP has a standard definition of done that includes running tested features deployed to a production-like environment where users can see them (preferably to production, unless there is a business reason to batch finished stories up.)

#5 -- The concept of Whole Team belongs to XP. It is an explicit XP practice. Scrum has the notion of a cross-functional team, but generally excludes roles like SM, PO, Project Manager, etc. from the team, whereas XP explicitly includes them.

I find this sort of post really, really distasteful. XP and Scrum are two peas in a pod. There is absolutely no advantage to having proponents of one method attack a strawman version of the other. This kind of thinking only makes the whole community weaker.
Michael Sahota, CSC,CSP,CSM, 3/22/2011 3:58:44 PM
Adam, thank you for your comments. Apology and clarification posted here: http://www.agilitrix.com/2011/03/scrum-and-xp-are-not-what-you-think/

You must Login or Signup to comment.