Differences Between Scrum and Extreme Programming
This article has an audio version:    Download Audio Version

Scrum and Extreme Programming (XP) are definitely very aligned. 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. The differences are often quite subtle, but they are important. I think there are four main differences between Scrum and XP:

  1. Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long. XP teams typically work in iterations that are one or two weeks long.
  2. Scrum teams do not allow changes into their sprints. Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint. XP teams are much more amenable to change within their iterations. As long as the team hasn’t started work on a particular feature, a new feature of equivalent size can be swapped into the XP team’s iteration in exchange for the unstarted feature.
  3. Extreme Programming teams work in a strict priority order. Features to be developed are prioritized by the customer (Scrum’s Product Owner) and the team is required to work on them in that order. By contrast, the Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items. I’ve never seen a Scrum team not choose to work on the highest-priority item. And a Scrum team will very likely choose to work on the second most important. However, at some point one of the high priority items may not be a good fit for the sprint being planned—maybe a key person who should work on it will be swamped by work on higher priority items. Or maybe it makes sense to work on a slightly lower priority item (let’s say #10 on the product backlog instead of #6) because the team will be working in the code where #10 would be implemented.
  4. Scrum doesn’t prescribe any engineering practices; XP does. I love the 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. I love the XP practices but don’t like mandating them. I want teams to discover the value on their own.

These are small and often subtle differences between Scrum and XP. However, they can have a profound impact on the team. My typical advice to teams is “start with Scrum and then invent your own version of XP.” The XP practices are wonderful but they work best and teams commit to them the most stridently if they discover them 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?” I find true XP to be a small target off in the distance. If a team can aim at that and hit the bull’s eye, wonderful. If not, however, they are likely hacking (e.g., refactoring without any automated testing or TDD). Scrum is a big bull’s eye that on its own brings big improvements simply through the additional focus and the timeboxed iterations. That’s a good starting point for then adding the XP practices.


101 Ways to Get Inspired About Agile

101 Ways to Get Inspired About Agile

Get this free PDF of inspiring agile quotes when you sign up for Mike’s weekly tips email.

Get weekly tips from Mike Cohn

106

Posted:

Tagged:

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at [email protected]. If you want to succeed with agile, you can also have Mike email you a short tip each week.

106 Comments:

Yves Hanoulle said…

I agree with your remark about “self-organizing” and forcing people to use practises.
Self-organizing teams do not appear by itself.
There is a well know group dynamic that happens in all teams.
Forming, Storming, norming, performing
http://en.wikipedia.org/wiki/Forming-storming-norming-performing
Most groups never get past the storming phase.
Every phase needs a different kind of leadership style.
In the forming phase, a group needs a stronger leader. (They need this, to get quicker to the next phases.) And at that moment dictatin the xp practises could work.
When a team enters the norming phase, they will find their own “best practises”. It is also a phase were the leader will less interfear. Forcing there to use a certain practise, willl hold back the team.

Yves Hanoulle said…

I agree with your remark about “self-organizing” and forcing people to use practises.
Self-organizing teams do not appear by itself.
There is a well know group dynamic that happens in all teams.
Forming, Storming, norming, performing
http://en.wikipedia.org/wiki/F…
Most groups never get past the storming phase.
Every phase needs a different kind of leadership style.
In the forming phase, a group needs a stronger leader. (They need this, to get quicker to the next phases.) And at that moment dictatin the xp practises could work.
When a team enters the norming phase, they will find their own “best practises”. It is also a phase were the leader will less interfear. Forcing there to use a certain practise, willl hold back the team.

Mike Cohn said…

You’re absolutely right that teams in the early stages need stronger leadership. I’ve written elsewhere about something called “Situational Leadership” and how it applies to agile project management / ScrumMastering.

Mike Cohn said…

You’re absolutely right that teams in the early stages need stronger leadership. I’ve written elsewhere about something called “Situational Leadership” and how it applies to agile project management / ScrumMastering.

Yves Hanoulle said…

Exactly. I am interested to read your post about Situational Leadership”. Was the Forming-storming-Norming-perfoming also mentioned in the Ken Blanchard book? I don’t remember where I first heard about it.

Yves Hanoulle said…

Exactly. I am interested to read your post about Situational Leadership”. Was the Forming-storming-Norming-perfoming also mentioned in the Ken Blanchard book? I don’t remember where I first heard about it.

Mike Cohn said…

The trademark owners of the term _situational leadership_ have asked that I not post my paper on that subject on the web. However, I can share information with anyone on the subject if you email me at .(JavaScript must be enabled to view this email address). Forming, Storming, Norming and Performing come from Bruce Tuckman, not Ken Blanchard.

Yves Hanoulle said…

I know it was from Tuckman, but I wondered/wonder if it was mentioned in Blanchard’s books

Mike Cohn said…

I’m sorry I misunderstood your question. No, Forming-Storming-Norming-Performing is not mentioned in Blanchard’s books to the best of my recollection.

Mike Cohn said…

I’m sorry I misunderstood your question. No, Forming-Storming-Norming-Performing is not mentioned in Blanchard’s books to the best of my recollection.

Jay Conne said…

Mike, I like your distinctions above and Yves comments about the team’s learning process.  A couple of fine points:

- I’m finding that Scrum teams with the courage to try 1-week iterations love the rate of learning and productivity they achieve.  A recent example is Kaplan-IT where after a number of iterations, they are loving it.  So I don’t think of that as key distinction. 

- I worked with Ron Jeffries on two recent programs, one consulting and the other the Deep Agile - Professional Development ACM Seminar here in Boston.  He was of the opinion that XP was all you needed and Scrum was just one of those ego serving brands.  I think he has a new appreciation after these experiences - the later sharing the 2-day single-track program with Jeff Sutherland.  Perhaps his views are typical of some of the XP community.  You and Jeff agree on the distinction Scrum-XP.  I have now come to a couple of simplifications that I think serve my clients well: 

—Scrum is an interaction model that builds trust and flow between members of a cross-functional creative team; and between that team and those that are paying for their product.  Then, quoting Scrum explicitly, ‘Scrum wraps good business and engineering discipline’. 

—A good SW engineering discipline comes from XP with a collection of practices that can be introduced as the context allows. 

—A good business discipline comes from lean thinking .. with appropriate references.  I use Rob Thomsett’s project start-up approach to capture and ‘radiate’ the project’s global goals, scope, dependencies and success trade-offs.  This is placed high on the wall, above the task board and burndown chart.

Jay Conne said…

Mike, I like your distinctions above and Yves comments about the team’s learning process.  A couple of fine points:

- I’m finding that Scrum teams with the courage to try 1-week iterations love the rate of learning and productivity they achieve.  A recent example is Kaplan-IT where after a number of iterations, they are loving it.  So I don’t think of that as key distinction. 

- I worked with Ron Jeffries on two recent programs, one consulting and the other the Deep Agile - Professional Development ACM Seminar here in Boston.  He was of the opinion that XP was all you needed and Scrum was just one of those ego serving brands.  I think he has a new appreciation after these experiences - the later sharing the 2-day single-track program with Jeff Sutherland.  Perhaps his views are typical of some of the XP community.  You and Jeff agree on the distinction Scrum-XP.  I have now come to a couple of simplifications that I think serve my clients well: 

—Scrum is an interaction model that builds trust and flow between members of a cross-functional creative team; and between that team and those that are paying for their product.  Then, quoting Scrum explicitly, ‘Scrum wraps good business and engineering discipline’. 

—A good SW engineering discipline comes from XP with a collection of practices that can be introduced as the context allows. 

—A good business discipline comes from lean thinking .. with appropriate references.  I use Rob Thomsett’s project start-up approach to capture and ‘radiate’ the project’s global goals, scope, dependencies and success trade-offs.  This is placed high on the wall, above the task board and burndown chart.

Jason Novack said…

Mike, I agree mostly with your summary.  However, I can’t say I have ever come across a developer who would ever come to the conclusion that pairing is a great practice and implement it on their own.  I’ve always had to nudge my teams towards it. 
I’ve seen developers spend hours trying to debug what ends up being a simple issue that, if paired would have been caught in minutes.  Once they do it, they recognize the value in it, but still seem reluctant to keep up the practice, it seems to be a pride thing where they always want to figure it out themselves.  Or maybe it’s just the brilliant, but stubborn developers we have. 😊

Jason Novack said…

Mike, I agree mostly with your summary.  However, I can’t say I have ever come across a developer who would ever come to the conclusion that pairing is a great practice and implement it on their own.  I’ve always had to nudge my teams towards it. 
I’ve seen developers spend hours trying to debug what ends up being a simple issue that, if paired would have been caught in minutes.  Once they do it, they recognize the value in it, but still seem reluctant to keep up the practice, it seems to be a pride thing where they always want to figure it out themselves.  Or maybe it’s just the brilliant, but stubborn developers we have. 😊

David McLean said…

I have little XP experience but some of the developers here are keen on introducing it and I don’t want to roll that out without making a case to the business.
Your article is focussed on the differences for the software team - can you expand on these to consider the commercial difference? When is XP likely to benefit business over scrum or visa versa? Is that purely based around the frequency of added value? Considering Jay’s comments above, scrum can be just as good at geting value delivered every week as XP is, and we have 2 teams who do that successfully now; will they do better if they use XP?.
Is it simply the case that there is no commercial difference; i.e. they deliver equal commercial benefit so just let the developers choose what they prefer?

David McLean said…

I have little XP experience but some of the developers here are keen on introducing it and I don’t want to roll that out without making a case to the business.
Your article is focussed on the differences for the software team - can you expand on these to consider the commercial difference? When is XP likely to benefit business over scrum or visa versa? Is that purely based around the frequency of added value? Considering Jay’s comments above, scrum can be just as good at geting value delivered every week as XP is, and we have 2 teams who do that successfully now; will they do better if they use XP?.
Is it simply the case that there is no commercial difference; i.e. they deliver equal commercial benefit so just let the developers choose what they prefer?

Mike Cohn said…

Jason, while I can agree that many (and possibly most) developers will not implement pairing on their own, I have seen *some* do so. Your use of the word _nudge_ is interesting because that is exactly how I describe it. I view part of the ScrumMaster / Coach / Mentor’s role as nudging the team in directions such as pairing and test-driven development. I usually do that by asking a lot of questions, such as, “Hmm, would that bug have been released if we’d been pairing?” or “What could we have done to prevented this?” The wording of the question and the time I ask it are carefully chosen to help teams realize that maybe there is something to good practices that they just haven’t adopted yet. I’m fairly optimistic and think that most good developers when working in a good context (good company, good project) will choose to do most of the right practices.

Mike Cohn said…

Jason, while I can agree that many (and possibly most) developers will not implement pairing on their own, I have seen *some* do so. Your use of the word _nudge_ is interesting because that is exactly how I describe it. I view part of the ScrumMaster / Coach / Mentor’s role as nudging the team in directions such as pairing and test-driven development. I usually do that by asking a lot of questions, such as, “Hmm, would that bug have been released if we’d been pairing?” or “What could we have done to prevented this?” The wording of the question and the time I ask it are carefully chosen to help teams realize that maybe there is something to good practices that they just haven’t adopted yet. I’m fairly optimistic and think that most good developers when working in a good context (good company, good project) will choose to do most of the right practices.

Mike Cohn said…

Hi David—As far as business impact differences between Scrum and XP I don’t think you’re likely to find huge differences over the long run. I think that whether a team starts with XP or starts with Scrum they will end up in the same place eventually. Since Scrum doesn’t advocate any specific engineering practices the teams are left to devise them on their own. Most eventually pull in what they feel are the “best parts” of XP’s technical practices. So you’ll find Scrum teams doing Test-Driven Development (TDD) and continuous integration, etc.

In terms of value to the organization, each will end up delivering the same value. Starting with Scrum has the advantages of being an easier starting point that is a little less risky (those engineering practices are often hard to adopt in our real-world contexts). Starting with XP has the advantages of getting past some of the technical hurdles earlier.

Mike Cohn said…

Hi David—As far as business impact differences between Scrum and XP I don’t think you’re likely to find huge differences over the long run. I think that whether a team starts with XP or starts with Scrum they will end up in the same place eventually. Since Scrum doesn’t advocate any specific engineering practices the teams are left to devise them on their own. Most eventually pull in what they feel are the “best parts” of XP’s technical practices. So you’ll find Scrum teams doing Test-Driven Development (TDD) and continuous integration, etc.

In terms of value to the organization, each will end up delivering the same value. Starting with Scrum has the advantages of being an easier starting point that is a little less risky (those engineering practices are often hard to adopt in our real-world contexts). Starting with XP has the advantages of getting past some of the technical hurdles earlier.

Brian Kierstead said…

We’ve been doing Scrum for the least year or so and have slowly added in some XP practices as we’ve gone along.  When its comes to project management Scrum rules.  For engineering practices we look to XP.  If there is an overlap, we follow Scrum.  But there isn’t really much of a problem - they are very different things.

Brian Kierstead said…

We’ve been doing Scrum for the least year or so and have slowly added in some XP practices as we’ve gone along.  When its comes to project management Scrum rules.  For engineering practices we look to XP.  If there is an overlap, we follow Scrum.  But there isn’t really much of a problem - they are very different things.

Torbjrn Kalin said…

Very interesting, especially point number 4. You could say that Scrum is more agile in this sense than XP: Value individuals over processes. Scrum is a “pull system” while XP is a “push system”, to use Lean terminology.

Torbjrn Kalin said…

Very interesting, especially point number 4. You could say that Scrum is more agile in this sense than XP: Value individuals over processes. Scrum is a “pull system” while XP is a “push system”, to use Lean terminology.

Mike Cohn said…

Torbjrn—
Oooh, excellent point about push/pull. That is a fantastic way to think of the difference. Thank you for that.

Joakim Karlsson said…

How often do you find that the inspect and adapt approach of Scrum leads to teams using the engineering practices of XP eventually?

I have a feeling that in a way Scrum and XP are both means to the same end. Two ways of introducing basically the same value system and practices to an organization. I would love to hear about a Scrum project that took the team far from the practices of XP.

Joakim Karlsson said…

How often do you find that the inspect and adapt approach of Scrum leads to teams using the engineering practices of XP eventually?

I have a feeling that in a way Scrum and XP are both means to the same end. Two ways of introducing basically the same value system and practices to an organization. I would love to hear about a Scrum project that took the team far from the practices of XP.

Mike Cohn said…

Hi Joakim—
Unfortunately there are many teams who start with Scrum and decide that the basics of Scrum are enough. They forget that Scrum calls for continuous improvement through its retrospectives and the inspect-and-adapt mechanism at its core. So they stop after adopting the simple mechanics of Scrum. They’re much better in almost all cases than where they started but they are far short of where they could get to.

I have seen Scrum teams that go somewhat different directions than XP—they will decide that having a single person who owns an area (the FDD “Chief Programmer” model) is best or they will decide to designate a tech lead among themselves or they’ll decide to do Fagan-style code inspections rather than pair. Many decide that “test-right-after-development” is good enough and don’t go to TDD. Still, given enough time and the right nudges at the right times by a good coach I think that Scrum and XP teams do end up at roughly the same place.

Mike Cohn said…

Hi Joakim—
Unfortunately there are many teams who start with Scrum and decide that the basics of Scrum are enough. They forget that Scrum calls for continuous improvement through its retrospectives and the inspect-and-adapt mechanism at its core. So they stop after adopting the simple mechanics of Scrum. They’re much better in almost all cases than where they started but they are far short of where they could get to.

I have seen Scrum teams that go somewhat different directions than XP—they will decide that having a single person who owns an area (the FDD “Chief Programmer” model) is best or they will decide to designate a tech lead among themselves or they’ll decide to do Fagan-style code inspections rather than pair. Many decide that “test-right-after-development” is good enough and don’t go to TDD. Still, given enough time and the right nudges at the right times by a good coach I think that Scrum and XP teams do end up at roughly the same place.

Mark Randolph said…

When asked the relationship between Scrum and “Extreme” or XP programming, my view is Scrum provides a project management “wrapper” that enables—and protects—XP practices in ways classic management cannot.

Mark Randolph said…

When asked the relationship between Scrum and “Extreme” or XP programming, my view is Scrum provides a project management “wrapper” that enables—and protects—XP practices in ways classic management cannot.

DeanG said…

Thanks for the clarification.  In lurking the Scrum list I had come to the expectation that Certification classes taught that Test First, Continuous Integration/Nightly Builds, and bull pens were a near-requirement for successful Scrum.

DeanG said…

Thanks for the clarification.  In lurking the Scrum list I had come to the expectation that Certification classes taught that Test First, Continuous Integration/Nightly Builds, and bull pens were a near-requirement for successful Scrum.

Mike Cohn said…

Those are great practices and I’d want all teams to adopt them eventually. But the beauty of Scrum is that it is about incremental improvement. Start where you can and improve.

Mike Cohn said…

Those are great practices and I’d want all teams to adopt them eventually. But the beauty of Scrum is that it is about incremental improvement. Start where you can and improve.

SpaceCowboy said…

Eek sorry i might have missed the blog postings for this one, think im about several months too late - but thought i’d reply all the same since this has article came up on my search.

Mike another odd ball difference i noticed recently when trying to use extremeplanner as a tool for scrum was how i was being forced to use ideal days and not story points.

Scrum and general agile readings promote story points, i love this idea, and XP does an equivalent thing with its 1wk, 2wk, 3wk estimation units. But why the difference?

Ive waded through articles and books to try and see why XP does this and scrum does the other but everything i read on scrum they say story points rule and everything i find on XP ideal weeks rule.

Infact i began digging into XP with scrum, and EVERYTHING i read used ideal weeks when estimating and not story points.

SpaceCowboy said…

Eek sorry i might have missed the blog postings for this one, think im about several months too late - but thought i’d reply all the same since this has article came up on my search.

Mike another odd ball difference i noticed recently when trying to use extremeplanner as a tool for scrum was how i was being forced to use ideal days and not story points.

Scrum and general agile readings promote story points, i love this idea, and XP does an equivalent thing with its 1wk, 2wk, 3wk estimation units. But why the difference?

Ive waded through articles and books to try and see why XP does this and scrum does the other but everything i read on scrum they say story points rule and everything i find on XP ideal weeks rule.

Infact i began digging into XP with scrum, and EVERYTHING i read used ideal weeks when estimating and not story points.

Mike Cohn said…

SpaceCowboy—
That’s an interesting observation. XP doesn’t mandate and Scrum doesn’t mandate story points. However, Kent Beck in the second edition of his XP book came out in favor of ideal time and I think that has pushed that approach in XP circles. Kent’s reasoning was that ideal time shows greater transparency into the process and is therefore a more honest approach. (I’m paraphrasing but that’s the gist of it.) While that may be somewhat true it is akin to saying that large companies should report earnings and all financials down to the penny because it’s more honest and accurate—perhaps, but doing so gets in the way of understanding.

I favor story points because we can abstract away many of the problems we have with time-based estimating, especially that my time cannot be added to your time in a reasonable way. That and the other compelling advantages of story points as a product backlog estimating unit outweigh the minor potential advantage of ideal time being more transparent.

Mike Cohn said…

SpaceCowboy—
That’s an interesting observation. XP doesn’t mandate and Scrum doesn’t mandate story points. However, Kent Beck in the second edition of his XP book came out in favor of ideal time and I think that has pushed that approach in XP circles. Kent’s reasoning was that ideal time shows greater transparency into the process and is therefore a more honest approach. (I’m paraphrasing but that’s the gist of it.) While that may be somewhat true it is akin to saying that large companies should report earnings and all financials down to the penny because it’s more honest and accurate—perhaps, but doing so gets in the way of understanding.

I favor story points because we can abstract away many of the problems we have with time-based estimating, especially that my time cannot be added to your time in a reasonable way. That and the other compelling advantages of story points as a product backlog estimating unit outweigh the minor potential advantage of ideal time being more transparent.

Michael Decascos said…

Scrum, XP , FDD, etc the name of the process does not matter. The teams should look at Agile practices from a broader perspective.

Michael Decascos said…

Scrum, XP , FDD, etc the name of the process does not matter. The teams should look at Agile practices from a broader perspective.

Prasad said…

Well said Mike.. I really appreciate having process organised in the initial stages. It is good move to start with Scrum initially and to go ahead with XP for those who are following XP else, It would be a complete mess for training novices who are jumping directly to XP in the upfront

Prasad said…

Well said Mike.. I really appreciate having process organised in the initial stages. It is good move to start with Scrum initially and to go ahead with XP for those who are following XP else, It would be a complete mess for training novices who are jumping directly to XP in the upfront

Adam Lider said…

Torbjrn Kalin said:
“Scrum is a “pull system” while XP is a “push system”, to use Lean terminology.”

What?

Mike Cohn answered:
“Oooh, excellent point about push/pull. That is a fantastic way to think of the difference. Thank you for that.”

I’m big fan of your blog and books, but this sentence made me sad. I can understand that wrong adoption of XP can be similar to “push system”  but only the adoption not the methodology itself. XP as a Scrum are built upon Agile philosophy which can not be source of any “push system” because of the values it promotes. When i read Agile Manifesto first time i didn’t know about terms “push” and “pull” systems but i felt it in the right way - as a base for pull systems (i found that when i read about TPS). Maybe there is not separate value for this but for example the first one: “Individuals and interactions over processes and tools” is about it in a little indirect way. In my opinion of course.

Mike Cohn said…

Hi Adam—

When I read Torbjrn’s initial comment about scrum being more pull and xp being more push, it seemed to summarize a difference. Looking back at it above, I can’t remember exactly what it was. I think it had to do with how the team’s plan or execute sprints. I’ve been trying for the last 45 minutes to recall what it was that felt right about that statement and I can’t.

Since both XP and Scrum are built from the same principles, they won’t (as you allude to) ever differ very much. In fact, if someone were to visit a team that I’d coached for a long enough period, you wouldn’t be able to really tell which they were doing—Scrum or XP. In my mind, the ending point (after lots of continuous improvement) is the same whether a team starts out doing what they think of as Scrum or XP. Some of the language will be different (words like ScrumMaster and sprint) but most all else will be the same over longer periods of time.

Adam Lider said…

Generally i don’t link this comparison, because XP an Scrum are not from the same league. XP is complete method which works great when adopted in appropriate way. The problem is that sometimes it’s hard to do it in some environments/teams especially big with long history with push system. In such cases Scrum can help (as mentioned above) as a method which helps feel Agile easier.
There is not option to XP for me, you have to adopt it. But most important is to feel Agile and Scrum can help in this area.

I found that Scrum can also help when talking about Agility with management. Because (i don’t know why) some people think like that: XP ~ pair programming. And because pair programming seems to cost more so getting approval can be harder.

BTW: Why there are commercial trainings and certificates for Scrum and not for XP?

Turk said…

From a team building standpoint do you feel that there are different types of people/personalities that just are not capable of performing in an Agile environment?  If you have decided to become an Agile or XP shop is this done with the people on your team in mind, or based on the product/solution you are trying to produce?

Great post!

Mike Cohn said…

I’ve seen individuals whose minds are so resistant to change that I recommended against adopting an agile approach to those clients. So, yes, there are some personalities that won’t do well in an agile environment.

Abhinav Vaid said…

I have liked Mike’s reply in the current thread. But yes I wanted to point our another factor I have seen which significantly changes the way its implemented. I am referring to “. XP doesn’t mandate and Scrum doesn’t mandate story points…..”. Well, this along with many other points that are being talked about are very subjective. At the end of the day it all matters as to how the management wants to get it implemented. 2 Options here (highest level):

1. Mandate it strongly (enforcing a compliance). 

2. Do it making the people to realize and taking their confidence and coaching them giving them realtime project examples/case studies which have worked.

Unfortunately, I have implemented on the lines of the 1st option(mandate had come from the top most management and I was the test manager). Result: it was very much successful but the guys involved the project find it disgusting and being used as tool to the team members on their toes. Any suggestions from anyone on this will be highly appreciated.

Mike Cohn said…

Mandating anything is almost always a bad way to go. This is one of the reasons I like starting with Scrum—it mandates very very little. I then push teams to discover better ways of working. What I hope they do is invent for themselves the XP technical practices since, in general, I’m a firm believer in them.

Lavanya said…

Mike,

I just got a chance to read this post. Simply beautiful and well drafted. I would like to read about PM’s everyday issues and answers.

Can you help me with the pointers please ? If they are your post, I dont need the others.

Regards,
Lavanya

Mike Cohn said…

Hi Lavanya—
You should be able to find many pointers for project managers everyday issues throughout this blog.

Trivender Singh said…

Hi Mike,

Enjoyed reading your article. A few thing I would like to say.

I like both of these Agile Techniques and find them really useful. Do you agree with me in saying that the underlying principles are mostly common between these two practices?  Both XP and Scrum promote better collaboration, communication, iterative/incremental development and frequent releases. Or in short take baby steps!!..

Scrum Iterations always focuses at delivering business values. Each sprint should add some business value to the product. XP iterations not always deliver business value. for ex. doing code refactoring /code review is an important part of XP but will not always deliver a new business functionality.

Scrum is generally easy and quick to adapt whereas adapting XP practices is always a bit of a struggle. For example it will take a while to change the developers mindset to accept pair programming. Or it will take some time to learn development tools for Unit testing, refactoring adapt the Test driven approach to Development.

Regards,
Trivender

Mike Cohn said…

Hi Trivender—
Yes, I think the principles that underlie XP and Scrum are the same. I also think that a well-coached team that starts with either XP or Scrum will end up at the same place. That is, over time as the team makes the process more of their own, it should be hard to know if a team started with XP or Scrum (except for the unusual Scrum vocabulary).

I also agree that it can be harder to introduce the XP technical practices than it is to introduce the more management-oriented Scrum practices.

Afshar Mohebbi said…

this text described differences between XP and Scrum very well. Thanks Mike!

Mike Cohn said…

Thanks, Afshar.

Louis Richer said…

Hi Mike,

I just read Agile Estimating and Planning, great book! I have been leading teams applying an XP based process for the past 5 years and found your book an effective virtual coach helping to point out some of the ways in which I have strayed from my “game”, thanks. That said, I found it a bit surprising that most of the instances in the book when you referenced the development team, you identified the test database developer, the Html developer, the acceptance testing automation team.  I got the distinct impression (which appears to have been mistaken based on this post) that you frowned upon pairing.  Did you intentionally omit all reference to pairing in your book, and if so why? Was it out of concern for alienating traditional managers who would see the practice as a huge waste?

Again great book,

Thanks,

Louis

Mike Cohn said…

Hi Louis—
I’m glad you liked Agile Estimating and Planning. Thank you.

I’m actually a big proponent of pair programming. I coach teams to do it maybe 50-75% of the time. It’s not needed 100% of the time as some things are just easy enough that an informal code review after is good enough. Plus there are always times when it’s just plain inconvenient (an odd number of people available because someone is out sick, etc.). I tend to write about one person rather than one pair because I find it easier to introduce concepts that way. Similarly, when I teach a Scrum class, I talk about how to do it with one team before introducing coordinating teams.

Nilanjan said…

Mike - I am puzzled by your saying there are *minor* differences between xp and scrum.  Your 4th point - engineering practices are what I see as major differences.  Given the lack of description of engr. practices, I have seen variations of scrum which don’t seem right - mini-waterfalls, testing phased between sprints.  I also don’t see how scrum can ensure product quality, or it leaves many questions (in my mind?) on how to maintain the same levels of quality as a traditional process

Mike Cohn said…

Hi Nilanjan—
I was puzzled too so I reread my post—I didn’t say there are “minor” differences. I said there are subtle differences that can have a profound impact.

The fact that Scrum is silent on many things is both its main strength and its main weakness. Scrum, for example, does not say a team should use a version control system. Yet, all good Scrum teams I’ve seen do. A good Scrum team will find appropriate technical practices to ensure high quality. A bad Scrum team (if they can be said to be doing Scrum) will use Scrum as an excuse to do low quality work.

embedsoftdev said…

I also write an article about Scrum and Extreme programming too, I use some resource from you website but not copy you content , Thank you very much for this useful article.

clewis said…

I am curious if there are differences in quality between scrum and xp.  scrum doens’t mandate or give guideliness around code coverage and refactoring whereas xp does.  i think in both the collaborative nature of the design is good in that there is strong buy in and (hopefully) consistent patterns and practices but doesn’t speak to the possibility that no one might have strong design/architecture skills.  there are many code monkeys that produce stellar code given a few parameters but ask them to architect a scalable system and they are in over their head. [btw - mean no disrespect in that regard because there is a ton of value these folks bring.]

Mike Cohn said…

Hi Chris—
That’s an interesting question but I haven’t seen any studies done addressing that specifically. It would be an interesting pursuit for an academic. Hopefully one picks up the topic.

Nicky said…

Mike,
what kind of project do you think more worth/or fit to use Agile development process?

thanks
Nicky

Mike Cohn said…

Hi Nicky—
That’s a bit offtopic for the title of this blog post but I am planning next week to write something for an early January blog post. I’ll write a new blog post on that topic. Thanks.

Nicky said…

hi Mike,

thanks for your information, I’m looking forward to read your new blog post.

thanks
Nicky

Alexis La Joie said…

Your last point about wanting to allow XP practices to develop on their own, intrigued me. It seems that XP and Scrum approach the development team from opposite ends of the spectrum. Scrum is imposed as a management tool by management on the team, while XP emerges from introspective development teams seeking to improve their practice. Both require bravery and a leap of faith to get the most out of them. XP requires management who is open to letting the development teams struggle and develop best practices which work for them. That can require a great deal of bravery from a manager who has pressure to show continuous productivity. At the same time, Scrum being imposed from above requires development teams to be brave enough to trust that the management using Scrum will allow them to be introspective enough to explore improving their process. Another way of putting it: XP starts with developers trying to improve the quality and efficiency of their work and then requires management to figure out how to harness the teams productivity, while Scrum starts with a management initiative and leads to developers trying to find ways to improve their quality and efficiency within the particular Scrum implementation.

Mike Cohn said…

Hi Alexis—
I can largely agree but with a couple of notable exceptions. I rarely see Scrum being “imposed as a management tool.” Probably 3/4ths of the Scrum implementations I get involved with were started by developers who were looking for ways to get more done. They then solicited management’s support in doing Scrum. Since Scrum is somewhat management-friendly, the developers were successful in getting this support.

I’m also not sure about the idea that XP requires management to “let development teams struggle and develop best practices which work for them.” XP is pretty clear about which “best practices” to start with. In fact, the early days of XP required a team to do all 12 practices or they “weren’t doing XP.” This has always struck me as the big anomaly in XP: XP says to a team, “We trust you to solve this business problem but hey, here are 12 technical practices you must do.” It always seems a little backward to trust a team to solve a business problem yet tell them the practices to follow even though the team members have solid technical backgrounds.

By the way, I should add that I have no particular bias between these processes. Visit a team I coach and wear some headphones while you’re there and you won’t know if they are doing Scrum or XP. You’ll see Scrum things like burndown charts and a person who seems to be protecting the team. But you’ll also see pairing, test-driven development, continuous integration, etc. (Why the headphones? Because you will hear all the weird Scrum vocabulary from the teams I coach.)

Thanks for your comment.

Alexis La Joie said…

Mike,
it is interesting how much diversity there still is in the market. I am glad to hear development teams using adopting Scrum to communicate well with management. My experience has differed, but I see your point. I guess I am also looking more primordially at each. It has been my understanding that XP evolved from developer best practices and then became a dogma. Scrum specifically omitted development practices because it wanted to avoid the pitfall you described and also be more management friendly/focused. If XP evolved from a dev team/teams who was formalizing their best practices, it would not be difficult for the typical developer mindset to say… this works… use it - otherwise it doesn’t. This ‘might’ account for some of the dogma in the XP realm - the nature of the players. At the same time, the successful XP teams I have been on started as XP-Lite (or some other similar euphemism). The part they got right and allowed them to succeed was the feedback loops and introspection/retrospection. They took refactoring their practice seriously. While they initially did not see need for all of XP, by the time they were into it for a while, their own candid reflections led them to full adoption over time. I have seen similar starts on the Scrum side (where they call their implementations Scrum-but). For some reason, these lukewarm Scrum implementations never see full Scrum adoption the way the XP teams did. I have some theories as to why, but am not sure if they are universally applicable. I would love to hear your thoughts.

Mike Cohn said…

Hi Alexis—
I have not seen a significant difference between teams that start with XP or Scrum in which continue on to continuous improvement. Too many of both types of teams get complacent after a first round of improvements and stop. I suspect the reason that XP teams you’ve been on continued to improve is because those teams had you and perhaps others like you who cared enough to continue to improving. Quite seriously, the fact that you read and comment on an agile-oriented blog probably puts in the top 1-2% of people passionate about what they do. A person or two like that on a team makes a huge difference. It’s also why I don’t see as much ScrumBut as I hear about. A team that calls me in to consult must have someone around who cares about improvements so they are less likely than the average to be doing ScrumBut. (They’re likely doing ScrumWithStruggles but that’s different from a team that rationalizes away the hard parts as is the key factor in making a team ScrumBut.)

Dave Singh said…

I thought, TDD is a common practice in both Scrum and XP?? Per my experienece, pair programming is not something mandated and does not fall under any methodlogies as such? I have led teams and seen developers are writing and exchanging codes by sitting at the single desk while working on waterfall and spiral models. Having said, if this’s true then what other differences are b/n Scrum and XP except A.? XP task is amendable B.> task goes like 1-2 weeks.

So, my question here is that what o

Dave Singh said…

I thought, TDD is a common practice in both Scrum and XP?? Per my experienece, pair programming is not something mandated and does not fall under any methodlogies as such? I have led teams and seen developers are writing and exchanging codes by sitting at the single desk while working on waterfall and spiral models. Having said, if this’s true then what other differences are b/n Scrum and XP except A.? XP task is amendable B.> task goes like 1-2 weeks.

Mike Cohn said…

Hi Dave—

TDD is absolutely a common practice in both Scrum and XP. The point here was that XP insists (less so now that earlier XP) that teams do TDD. Scrum doesn’t insist on any specific technical practices, leaving those entirely up to the team. Many good Scrum teams of course opt to do TDD. So the difference here isn’t whether teams do TDD, it’s whether they pick it as a good practice on its own (Scrum) or whether it’s done because it’s a mandatory part of the process. We could say something similar but in the opposite direction about daily standup meetings.

Prasanth Pillai said…

Hi Mike,

I read your article and now, I could understand the difference between XP, Scrum & pair programming. I just knew that, all these are different flavors of AGILE methodology.

I have few questions,
1. To become a scrum master, what one must have? ( precisely I am asking, does the person needs to be technical? lead? or a manager?  Or can a developer become a scrum master?)

2. Is there any role like scrum master in XP? As per this article, it looks like scrum master drives the XP as well. Is my understanding correct?

Regards,
Prasanth

Mike Cohn said…

Hi Prasanth—
I do not think a ScrumMaster needs to be technical. That’s nice but not even close to a requirement. You may want to look at this article on the Six Attributes of a Good ScrumMaster I wrote a few years ago.

XP has a role called “coach” which is somewhat similar to a ScrumMaster. But the XP coach is much more likely to be technical in my experience.

M. Simon said…

“At first I was iridescent. Then I became transparent. Finally I was absent.”  From a song about extreme programming.

Asif Akram said…

I just started developing series of web based games to teach and practice SCRUM and Kanban. Till now I have just worked on a game called Ones game and can be accessed at the following URL:
http://users.ox.ac.uk/~oucs0107/OnesGame/

Please, try the version “Auto Mode with parameters” to run the game in auto mode with configurable parameters. This version of game also plots various graphs for visual feedback.

Comments and suggestions are most welcome.

Thiago Graciadio said…

Mike, for me its already obvious that a Scrum + XP formula has a big chance to work. I really don’t understand why still there’s not a official framework that uses both methods together. Do you have any guess about it?
By the way, nice blog.

Mike Cohn said…

Thanks, Thiago. I’m glad you like the blog.

I think the default combination of Scrum + XP has largely become Scrum. Teams start with Scrum and then hopefully add the XP practices. Back in the early 2000s there were some named processes like [email protected] that deliberately combined the two. None caught on.

Thiago Graciadio said…

First. Thank for the reply Mike.

I’m currently studying in my MBA, exactly this, a study of the gain that a mixture of Scrum + XP (full or partial) may cause.
I found some references to the [email protected] and XBreed in my research, but i never discovery why these things didn’t caught, and even didn’t found any official material to perfom a comparative analysis of them versus a single use of Scrum or XP.
Do you think that studies like this still can be done?

Mike Cohn said…

Hi Thiago—
I think your biggest challenge will be finding projects that are purely XP or purely Scrum so that you can compare them. Scrum teams not doing any XP practices are likely very early stage Scrum teams and so they won’t be particularly good.

[email protected] and XBreed didn’t catch on because not even their founders pushed them. They could tell they were hybrids that mixed things that people were already mixing.

stiby said…

Think your forth point is mute, because Scrum is a framework (not a process as started at the start of your article).

As scrum does not prescribe processes or techniques the emphasises is on continuous improvement within the team [At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly - 12 principles of Agile].

Most established teams use a mixture of practices which suit the team and business more rather than use a “prescribed set of best practices” [Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely - 12 principles of Agile].

Using a heavily prescribed process and following rules dogmatically is more like putting a square peg in a round hole.

You can’t compare scrum to scrum because the internal process for each team will be specific.

mikewcohn said…

Hi Stiby—

Fair point. I see the date on that post is 2007. It’s older than that, though, so it must have been re-dated. It probably goes back to 2003. I mention that because both XP and Scrum have changed a bit since then. Early 2000s XP was very adamant about “you must do these 12 practices.” Scrum has never said anything close to that—which fits your point about it being a framework. So, I’ll stand by the claim that a difference (at least back then) between XP and Scrum was that Scrum leaves the selection of engineering practices entirely up to the team whereas XP prescribes at least a core or starting set of practices.
In large measure this is why Scrum and XP fit so well together. XP is mostly silent on management practices except for a few it derived from Scrum. Scrum is entirely silent on the technical practices so well established within XP.

Morebodi Rekz Modise said…

Hi Mike nice post, however am truly confused to this methodologies in terms of which to use for my final year computing project, please advice

mikewcohn said…

I would use Scrum and if you are a programmer and can, mix it as many of the XP practices as possible such as pair programming, etc. Good luck on your final project.

Carlos Yáñez said…

Hello Mike

Great Post, I am doing my practices for MSEM in a small company in Germany and my project is about improve the development process(they work with Websites and eCommerce) so your article gave me an idea how to develop this process (start at least). I got this idea about your comments and the others too, SCRUM would be used as Framework for processes and XP for development? On the other hand, I was thinking to integrate an agile development and processes to accomplish the requirement´s analysis and designing (using modeling BPMN, UML for documentation) because during my pre evaluation (I did some questionnaires and meetings with developers) I got problems on those areas mostly.

Thanks.
Best Regards
Carlos

mikewcohn said…

Thanks, Carlos.

Scrum is definitely all about being a process framework and couples well with XP for technical practices. You won’t go wrong with that combo. I’m not a huge fan of UML for documentation—it can work but there’s a tendency for it to be too much. Requirements management is almost always listed on any survey of why projects fail so you’re in good company having that on your list of things to address. Good luck!

Carlos Yáñez said…

thanks for your comments!!

Haq said…

Anyone
Tell me the 2 Examples of Scrum and Xp

Nick said…

Good article! Thanks for sharing! I didn’t know much about XP, but it’s definitely sparked a curiosity.

Mike Cohn said…

It’s a great process.

Musthafa Soukathali said…

Mike,
You already made it clear that irrespective of which one you start with XP/Scrum, or add in between, one will end up in similar place in future.
My question is related to scaling these processes at larger level, say 100+ team members distributed globally, and underlying disparate platforms. Frameworks like SAFe bundle program and portfolio layers on the top (named as release trains) of group of scrums. So, when I need to scale to larger teams and systems, which one will complement/amenable to scaling? Will it be scrum or XP?

Mike Cohn said…

Neither truly addressed scaling to that level in its initial descriptions.

Musthafa Soukathali said…

Thanks Mike!
I read about how to scale the team in your book few years back.That was very helpful.
Since then, have you seen additional insights on effective scaling?
In particular, has the cloud (technically), SAFe (framework wise), and anything else has filled some earlier gaps?

Mike Cohn said…

The main insights on scaling are coming from both SAFe and as well an initiative called large-scale Scrum (LSS) led by Bas Vodde and Craig Larman.

Mike Cohn said…

The main insights on scaling are coming from both SAFe and as well an initiative called large-scale Scrum (LSS) led by Bas Vodde and Craig Larman.

Carlos J. Duarte said…

I think when a team starts in the agile practices is desirable to
establish certain rules beyond those dictated by the methodologies and
in that sense, consider it appropriate to mandate certain practices of
XP. Once team matured and reached beyond certain discipline, then yes, I
agree with you that the team itself decides which XP practices are
suitable for their performance.

John Jones said…

Thank you Mike cohn, This was very helpful to me, “Scrum is an iterative and incremental agile software development methodology for managing product development. – See more at: http://scrumprojectmanager.blo…

bgn9000 said…

Hi Mike, I do need your insights regarding something I am struggling a lot those days because many (more and more) people are trying Agile (with a lot of imposters and cargo cult) and jump on it with a magic keyword they add to sell it to management: Agile methodologies.
(Consulting firms are also adding cheap and fast… safe 😉 )
For instance, I like to say this:
“Devops isn’t about automation, just as astronomy isn’t about telescopes: Christophe Little
Agile isn’t about methodology, just as Devops isn’t about automation.”
Then I read again (not the first time) your post here about XP and Scrum.
I read also Ron Jeffries article and he is mentioning XP as a minimal methodology.
I know that Scrum is not a methodology but a framework to grow this Agile mindset (practice of continuous inspect and adapt).
So coming back to my initial question… regarding your quote:
“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. I love the XP practices but don’t like mandating them. “
A methodology is a recipe for some success while a framework is a tool that only you can make it a success.
Is-it because XP is a methodology (rules even minimal) and not framework (guidances) to grow a mindset Agile values and principles?
I hope this is not too much confusing.

bgn9000 said…

Very moderative, I like your answers. Nice to share with you those thoughts while I am building very fast (and a bit late, never late in fact) my coaching ability. Make sense that one doesn’t fit all even when it is about more or less prescriptive approaches. Anyway as you said for XP “I love the XP practices but don’t like mandating them. I want teams to discover the value on their own” I fell the same when I see it coming in my organisation. I try to keep myself agnostic on the techniques but I fell trapped. I thing we are missing the point if we go this way. I love XP too but when I moved later on Scrum I was happier because I discovered those values on my own finally.

Martin Hinshelwood said…

Does your #2 not conflict with the Scrum Guide?
A Development Team commits only to the Sprint Goal, not Scope, and the actual things that get done by them is open to change throughout the Sprint. As long as a new item is in keeping with the Sprint Goal then there is nothing in the Scrum Guide that sais one can’t change it!

Steve L said…

Can you remember when the scrum guide changed (or was it even pre-scrum guide) to remove the sprint backlog’s immutability ?  It makes perfect sense now, but at the time it was quite a big shift.  By the way Mike Cohn I downloaded your free scrum slide deck a few months ago and it still talks about making no changes to the sprint backlog during sprint.

Geoff Goodhew said…

I tend to go back to first principles. Agile in general owes a lot to Deming and the quality movement - best known now through Toyota. One of the primary tenants of this is to build quality into the production processes - reducing waste by reducing rework and failure rates.
So for scrum/agile to work well, you need engineering practices that build quality into the process. And XP practices like TDD (or BDD) and pair programming are excellent. If you don’t adopt these practices, then you still need to do something to ensure quality - usually captured in the DoD.
If you’re applying scrum to non-development work, then XP won’t make sense; but the quality imperative remains.