Scrum & XP: Better Together

15 April 2014

Scrum and Extreme Programming (XP) are two agile processes that work well in tandem. In fact, if you walked in on a team doing one of these processes you might have hard time quickly deciding whether you had walked in on a Scrum team or an XP team—both because their framework is similar and because Scrum teams often adopt XP practices, and vice versa.

XP and Scrum complement each other so well because, though they both embrace agile principles, they come to agility from different perspectives. While some of the differences between the two are mainly semantics (Scrum’s product owner is close to XP’s customers; Scrum’s sprints are XP’s iterations; and so on), others are more substantial. XP’s iterations are one or two weeks long, versus the usually longer two-week to one-month Scrum sprints. Scrum doesn’t allow any changes to the chosen sprint backlog after planning; XP allows teams to substitute a feature in exchange for an unstarted feature of equivalent size. At the same time, XP teams must always work in priority order; while Scrum teams can choose a lower priority item for a sprint if it makes sense for scheduling or coding. (For more details on these differences, check out my classic blog post: “Differences between Scrum and Extreme Programming.”)

Perhaps the biggest difference, though, is the very thing that makes these two frameworks so compatible. XP mandates a set of engineering practices; Scrum does not. At the same time, Scrum mandates planning ceremonies and artifacts, where XP does not.

My typical advice to teams is “start with Scrum and then invent your own version of XP.” I love the core XP engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on. However, I think it’s a mistake to say to the team “you're self-organizing, we trust you, but you must do these specific engineering practices….” This sends a mixed message to the team that causes confusion.

The XP practices are wonderful but they work best (and teams truly commit to them) if the team members decide to implement the practices themselves rather than having them mandated. I help teams do this in my coaching by asking questions like, “Would this bug have happened if we'd been doing test-driven development?” and “Would we have made that mistake if we were pairing?”

Scrum and XP are both valuable approaches to agility in their own right. Put them together, though and you have a wonderful blend of the management and technical practices teams need to function at a high level.

Article Rating

Current rating: 4.6 (7 ratings)
Comments
Mike Cohn
Hi Ron--
Yes, I agree with you on the risks of "XP But".
6/27/2014 2:10:30 AM

Ron Quartel
I agree with you that scrum and XP do go together but do worry about "XP but" when it comes to "inventing your own version of XP". To learn XP properly you need an XP coach just as to do scrum properly you have a Scrum Master. Scrum is simple but not easy. XP is even harder to get right than Scrum and you are likely to hit more resistance I have found. Thank you for the article as we need these to help fight the resistance battles!
6/24/2014 11:30:36 PM

Mike Cohn
Hi Roman--I don't see a problem with it either on a mature (experienced) team with a mature PO. Swapping stories should be allowed when all are in favor it. However, I think the Scrum rule is great when starting. It helps product owners learn that deciding what to ask for in a sprint is important and they can't just easily change their minds later. Once they've learned that, I lighten up the rule substantially.

Hi Roberto--Good point. Scrum still has a lot of software-specific stuff in it, but that's changing. XP really can't ever be anything but for software. (It would be hard for something with "Programming" in its title to move beyond software.) That's not a knock (in my opinion) on XP, more just a statement of difference--thanks for pointing it out.
6/5/2014 3:10:25 PM

Roberto
Thanks for posting Mike.
I would add one thing. The four values ​​of agilemanifesto - changing "software" with "xxxx" in the second - can adapt and improve many activities that require collaboration.
The Scrum framework is easily adaptable to other worlds. XP is much more related to software development
6/5/2014 1:54:36 AM

Roman Shtekelman
Thanks, Mike for this comparison, I was not aware of subtle difference with regards to swapping the stories during sprint permitted in XP and not in Scrum. Having said we just did exactly that on our project priority changed and we swapped one story with another of the same size. I did not feel that was a problem with it, however the purist of scrum would have said it is not allowed, but are not we agile and flexible and if the team agrees that it is OK than I see no reason why not do it.
6/3/2014 5:11:52 PM

Gene Gendel
Hey Mike, the cycle time to get it reviewed and posted is a few weeks. So i have to wait. I will share the link, once it is live. Best, gene
6/2/2014 5:56:45 PM

Mike Cohn
Thanks, Gene. I'll be looking forward to seeing your post.
6/1/2014 12:21:11 PM

Gene Gendel
Mike - the best part is this "XP mandates a set of engineering practices; Scrum does not. At the same time, Scrum mandates planning ceremonies and artifacts, where XP does not." :).
Anything that is hybrid frequently proves to be more effective then something 100%. Lets take hybrid cars, for example. I share your view and have a similar story to tell about two complimenting agile techniques. Will be posting separately and share the link:). Thanks for this great post.
5/31/2014 9:50:18 AM

Mike Cohn
You're welcome, Chris.
5/29/2014 3:47:57 PM

Chris Chan
Thanks for the short precise comparison.
5/29/2014 3:23:24 PM

Mike Cohn
Thanks, Steven.
5/25/2014 3:41:40 PM

Steven Crago
Thanks for posting Mike. Very informative.
5/25/2014 11:13:42 AM

Mike Cohn
Jai--
You are absolutely correct in all regards. Thanks for your comment.
4/26/2014 7:44:36 PM

Jai Singhal
Nice blog Mike!
Scrum and XP compliment each other. XP practices provide the essentials for the team to ascertain high quality. XP practices like Test Driven Development (TDD), Continuous Integration (CI), and Pair programming provide ways for the team to have collective ownership and high quality. Kent introduced iterations in XP after he learned it from Jeff. That is evident in similarity in the ceremonies and terms are also very close. The focus is on iterative and incremental development.

User stories, spikes, and story points are other aspects that are adopted from XP further enable estimating and planning aspects for backlog items.
4/25/2014 6:41:26 PM

Mike Cohn
Absolutely right, Thomas. I don't think it's very important where a team starts. What matters is that they focus on continually improving. If they do that, they'll end up with the right process for them.
4/23/2014 10:28:15 PM

Thomas Schnoege
Nice blog especially the small differences of XP and Scrum. I´ve seen a team walking from XP to Scrum. They came from a low quality production and XP gave them the practices to stop that. When they adopted most of the XP practices they focused more on the process and so they came to Scrum. Maybe it´s not so important where to start as long as you focus on your biggest obstacle.
4/23/2014 5:56:58 AM

Mike Cohn
Thanks, Zach.

One of the discussions in my Certified ScrumMaster course is whether the lack of technical practices is a strength or weakness of Scrum. It's always an interesting discussion because it is a bit of both. Sure, some teams really do need the mandate of "do these practices" or they don't make any hard changes to their process. But, I'm with you on starting with the framework and then pushing people to look for improvements once they start to feel comfortable with the basic framework. As you say, once that maturity develops, the XP practices become a great, next step.

Thanks for your comments.
4/20/2014 8:40:33 PM

Zach Bonaker
Nice, concise blog post Mike!

I tend to agree with you... once I get teams really comfortable with Scrum, encouraging aspects of XP really engages the team to reach the next level. They really do complement one another well.

I've read so many opinion pieces criticizing Scrum for the lack of mandated technical practices... but I think that's what helps organizations of varying skill to feel confident in starting Scrum. Once the framework takes off, people have gained the maturity that XP techniques are a great next step.

z
4/18/2014 6:24:37 PM

Leave comment



 Security code