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:
- 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.
- 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.
- 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.
- 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.
Tags: XP
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.
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.
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.
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 mike@mountaingoatsoftware.com. Forming, Storming, Norming and Performing come from Bruce Tuckman, not Ken Blanchard.
I know it was from Tuckman, but I wondered/wonder if it was mentioned in Blanchard’s books
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, 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.
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.
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?
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.
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.
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.
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.
Torbjörn–
Oooh, excellent point about push/pull. That is a fantastic way to think of the difference. Thank you for that.
Pulling XP. From Scrum…
Scrum and Extreme programming are the two most popular agile software development methods. Both ideally end in a situation when the team working in a short cycles iteration by iteration delivers the DONE features to the customer….
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.
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.
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.
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.
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.
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–
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.
Scrum, XP , FDD, etc the name of the process does not matter. The teams should look at Agile practices from a broader perspective.
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
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.
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.
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?
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!
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.
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.
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.
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
Hi Lavanya–
You should be able to find many pointers for project managers everyday issues throughout this blog.
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
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.
this text described differences between XP and Scrum very well. Thanks Mike!
Thanks, Afshar.
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
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.
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
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.
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.