There is often confusion about Scrum and XP. The are both Agile frameworks because both were represented as part of the creation of the Agile Manifesto and yet they have their differences. Is it possible to use elements of both? And, if we wanted to do that how should we go about it?
I tried to answer these questions as part of the 2010 Shanghai Scrum gathering and I’ve finally found time to created a version of that presentation suitable for the web. This is an abbreviated version of the full talk which lasted over 40 minutes but I tried hard to hit the key points. It’s just over 3 minutes long.
Finally here’s a copy of the original paper that talks about combining scrum and xp that I wrote with Ken back in 2002. It’s dated now, although it may give you some different ideas: http://www.informit.com/articles/article.aspx?p=26057
Transcript
This modified framework began the basis of Extreme Programming. Ken Beck and Ward Cunningham were not the only one to take this approach, Ken Schwaber, one of the co-creators of Scrum created his own personal approach which he called XP@Scrum. and Mike Beedle, Ken’s co-author on Agile Software Development with Scrum created a separate approach called XBreed. Simplicity has always been one of Scrum’s strength and it was decided that technical processes should remain outside of the Scrum framework.
This effectively divided Scrum and Extreme Programming into two separate camps. How do Scrum and XP differ? Both frameworks face a different emphasis on process. Allow me to demonstrate. Commonly, Scrum is described by the Scrum Roles, events or meetings and the artifacts. The diagram you see here is one of the more common diagrams that summarizes the Scrum process and was taken from Ken Travis’ first book.
Extreme Programming focuses on the technical aspects of product development. The technical practices can be grouped under common attributes including Feedback, Continuous process, shared understanding and programmer welfare. This diagram was created by Ron Jeffrey and illustrates the frequency of a lot of practices and their relationship to each other for example technical practices towards the center indicated by the blue circle are undertaken multiple times per day. Technical practices indicates indicated by the green circle may only be undertaken once a day.
Note the overlap of the two diagrams. Here the common processes between Scrum and XP become self evident, Scrum focuses always on big picture things, cultural and systemic change while extreme programming focuses inwards on the engineering themes. One common assumption is that Scrum is considered to be a project management approach, whereas XP is considered to be a combination of both project management and technical processes.
This is an over simplification of the true nature of the the respective frameworks. Despite the differences, there is a natural attraction between the two. Most high performing teams naturally use both Scrum and extreme programming together an example of this is extreme programming practice of continuous integration.
Without continuous integration, it quickly becomes impossible to produce an increment of potentially shippable product at the end of every single sprint. Scrum doesn’t explicitly mandate how a team should build the product but it will drive the team towards adopting the extreme programming technical practices after just a few sprints. Combining Scrum and extreme programming is a powerful way to take teams to the next level.
