Agile Zone is brought to you in partnership with:

Michael became a Certified Scrum Master (CSM) in 2004 and is huge advocate of better (XP) engineering practices since discovering unit testing in 2001. Michael has a B.A.Sc. from University of Toronto in Engineering Science and a M.Sc. from U.B.C. in Computer Science. He has presented at Agile Tour Toronto and the XPToronto/Agile User group on Scrum and XP. His is also an active member of the Agile community and co-organizer of Agile Tour Toronto. Michael lives and works in Toronto, Canada, as an independent Agile and Lean coach, consultant and trainer. Michael is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

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

03.01.2011
| 1871 views |
  • submit to reddit

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)
References
Published at DZone with permission of Michael Sahota, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Shumona Kapil replied on Sun, 2012/02/19 - 9:57am

A core shared principle is that the team owns it’s process. When you look at it this way there is no barrier between XP, Scrum, Crystal, etc. The c2 Wiki for instance is a treasure trove of advice and information for team who want to own their own process and engage in a conversation with their situation, rather then simply following someone else’s script. Granted following a script may be a way to get started, but it is not where you want to end up!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.