XP or Scrum, Either, Both, or Neither?

| by Amr Elssamadisy Follow 0 Followers on Oct 26, 2009. Estimated reading time: 4 minutes |

Which is better?  Scrum or XP?  Is there one that is more applicable than the other or is there another alternative? 

Tobias Mayer recently wrote on his blog Don't Do XP:

I am beginning to grow weary of the repeated discussions with the many who insist that Scrum doesn’t work without XP. Scrum works just fine — if applied with an understanding of the values and principles that are at its foundation. The context you implement Scrum in will determine the practices you need to apply. Scrum in Church will have a different set of good practices to Scrum in Software, and both will be different to Legal Scrum.

XP advocates are quick to blame Scrum for the lack of good development practices in the software industry. But given the very slow uptake of XP it could be argued (and I shall do so) that in fact XP itself is responsible for the lack of good practice in our industry.

It seems what Tobias is saying is that Scrum is enough to "pull" (in the Lean sense) the necessary technical practices and that does not require all of XP. XP is too much of a burden and it's lack of adoption is proof of that.

Steve Freeman responded to Tobias' post in Do do XP:

As an occasional XP advocate, I don’t “blame Scrum for the lack of good development practices in the software industry”, I blame the software industry. If we worked in an effective industry, we wouldn’t be having methodology wars because things would just work. Now this same industry is messing up Scrum too by just taking on its ceremonial aspects. On the other hand, to blame XP for blocking good practice is just bizarre.

XP is a tiny movement that attracted some attention. What XP (version 1) did achieve was to show that it is possible to break through the logjam of cautious procrastination that still cripples many development teams, but without resorting to hackery. It gave teams a reliable package of practices that just worked. Of course XP didn’t take over the world because it’s not suitable for everyone–not least because it requires a degree of focus and skill that is not appropriate for many teams. Kent Beck’s presentation of XP version 1 was extreme on purpose: it was designed to inspire us huddled masses, and to stretch the boundaries of what was considered possible in software development, to reframe the discussion.

Steve goes on to say that XP had much to do with the current emergence of the craftsmanship movement:

Tobias writes that the good development practices were spreading slowly at the time, but I’d argue that without XP we’d still be waiting. Test-Driven Development is still not that widely accepted and even the original C3 team didn’t adopt it fully until Kent was writing his book. Refactoring had a small academic following, but it’s not very safe without the compensating practice of TDD. I suspect most teams still ban changing code unless it’s to change a feature. Pair programming is still a very hard sell and, again, works much better in the context of TDD. I’ve seen enough Scrum teams that have not found a coherent set of technical practices. To say that they just need to improve their Scrum implementation begs the question of how Scrum is adopted and the limits of self-organisation.

This conversation, and many others, prompted Yves Hanoulle to suggest that maybe the Agile community is going through the second of the forming/storming/norming/performing cycle:

It looks like we have a lot of discussions where we question ourselves as an industry.

I have the feeling it is the first time this happens at this scale. Maybe I’m too young. Maybe I ‘m more in the middle now or have more idea’s myself on who’s right or wrong. Maybe it’s the always connect, twitterly, blogging world that makes these discussions so more public.

This reminds me a lot of the storming phase that exists in a team live cycle,or the chaos phase in Satir's model. So from a point of view of a coach these discussions and where this goes is interesting.

In these discussions, there is clearly no leader. Or let me put it in another way, no leader that everyone would accept.

So this contention in our community might actually be just a sign of our continuing maturity. This writer has found in his experience that everything makes sense in context. There have been successful teams that started with Scrum, and others that have been successful starting with XP, and many that have failed with both. The one thing that we do well at the Agile community is learn by experimentation and not lose sight that all of these practices and processes are only a means to an end.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Copy/Paste Error? by Dave Rooney

Amr, I think you have a copy & paste error with Steve Freeman's comment. I read it a couple of times, and it still looks exactly like Tobias'. :)

Agile vs. Brand by Jason Alcock

I see the title and content of this discussion as the problem created when people subscribe to a brand. Do it "XP" or do it "SCRUM". Without first taking on the fundamentals of Agile.

Applying Agile principles should be able to adjust SCRUM or XP to work in an environment. Following a process blindly is, as ever, unwise. Which I took as a starting point of Agile in the first place!

Scrum + XP FTW! by Robert Dempsey

The argument of using Scrum rather than XP rather than whatever else is senseless. Many companies ultimately adopt a hybrid approach, using Scrum and adding XP practices such as TDD, pair programming, and refactoring. Why do you have to choose one over the other? Are any of these one size fits all? I think not. And there is no need for them to be. Take a look at your current environment and team, look at where you want to go, see how each of the Agile practices can get you there, and start going down that road. Use what works best for you and, with guidance, you can be successful.

I am beginning to grow weary of these discussions.... by Bruce Rennie

I've been working in agile teams for over eight years now and I've only seen one implementation of what I would call "textbook" XP. All other teams were "Scrum-but" or "XP-like". And you know what? Most of these turned out just fine.

Scrum not working without XP by Scott Duncan

I guess I'm not upset when I hear this since I assume people are speaking about applying Scrum in a software development context. I don't presume they are talking about requiring XP when using Scrum in a Church setting, for example.

For me, the thing that is upsetting is when people suggest that, because Agile ideas came out of a software development context, they can only be applied properly in that context. So, for them "real" Agile is about software development and must address code development practices. I heard this position advocated at the Agile Roots Conference in Salt Lake City last June by some participants during discussions at the talks and over meals.

I agree completely with Jason Alcock: first understand the Agile Values and Principles. Then, the next thing to do is apply them in the context of an existing Agile method's practices and techniques. Only then "tailor" the practices and techniques.

Especially in large organizations, Agile adoption is becoming characterized by changing the practices and techniques before even trying to make them work. When I ask why, the responses are that they can't or don't need to do so given the way they currently work in the organization. The whole idea that pursuing an Agile approach is supposed to change how things work in the organization is either lost on or (implicitly) rejected by such instant "tailoring" of Agile concepts and practices.

Re: Copy/Paste Error? by Amr Elssamadisy

Fixed. Sorry folks for the error :)

Re: Copy/Paste Error? by Dave Rooney

Geez, I haven't done something that dumb since at least yesterday. :)

Possibly another point to be made by Amr Elssamadisy

While it is refreshing to hear that process are not the point and "Scrum or XP?" is the wrong question (for many years it seemed like it was the only question). I've got to think there is more to it than this.

Replace Scrum and XP with Project Management and Technical Practices, and the question is very valid? Can you do one without the other? Should you do one without the other? (I know, I know, it DEPENDS! )

Here's what I'm trying to get at, I think you generally need both. Your starting point may vary, you may start with the technical practices to build a foundation for the PM practices. Or you may start with the PM practices to create "pull" for the technical practices. But, in the end, is there a success without both in software development? (This is not a rhetorical question, I'm open to any answer.)

Re: Possibly another point to be made by Eric Bresie

I think this is similar to the issue touch on when comparing Software Engineers verses any other Engineer. I think part of this is about a maturity of process.

For mechanical engineers, over the years, they had to draw things manually (now with CAD thankfully) before they could build it, make models (physical models now possible with simulated models), or use algorithmic means to test things (record data, plot it out; thankfully data collection systems make this easier as well), build protypes, then final production versions. It took time.

In CMMI circles (Capability Maturity Model Integration) for example, they have different levels of maturity. Early phases you either don't have a process or you have a basic process which may include many different process for the same activities. As you progress, you formally establish process, unify process, measure peformance of process, and improve upon process.

I think along the way we also failed to except the work necessary (learning all the language, patterns, existing frameworks, etc) looking for the easy way out. If you want safe and quality software, you have to consider aspects of safety on the performance of the software which takes time.

This extra time cost money of course so maybe some aspects of program management are good here.

I think there is some "not invented here" syndrome mixed as well.

We sometimes failed to consider the risk for doing things so quickly.

With present technologies, we have been given a great opportunity. I hope we don't loose sight of that.

Re: Agile vs. Brand by Amr Elssamadisy

Applying Agile principles should be able to adjust SCRUM or XP to work in an environment. Following a process blindly is, as ever, unwise. Which I took as a starting point of Agile in the first place!

I'm not sure that I agree. When someone is new to a thing - anything - they are not ready to make context-dependent choices. They need a step-by-step, context-free, set of things to do. Then, once they truly learn by practicing they have the experience and knowledge to make effective tailoring decisions.

There is a large number of failed projects out there started by 1) having a successful experience with Scrum or XP, and 2) anointing those team members as experts and farming them out to start their own teams within the organizations when they just do not have the experience to tailor the process.

Just don't cut through the load-bearing walls by Robert Merrill

I agree with Yves Hanoulle that the "agile community" is going through the "storming" stage.

Agile is also crossing the chasm from early adopters to early majority. Early adopters were kind of agile to begin with, so the cultural change across the organization was easier.

But the early majority has PMOs, Governance Boards, Gated Processes, Roles as People (and an org chart that matches the waterfall phases), and a number of other toes to step on when Agile is introduced. So there's more pressure to modify whatever flavor of Agile is being introduced, and unknowingly cut through a load-bearing wall in the process. Down Agile falls, to a chorus of, "We tried that, and it didn't work," often sung by people whose cheese stood to get moved if it did.

IMO the key is understanding why agile methods work. What problems do they solve, and what are the load-bearing walls that form these solutions. Then you can mix-and-match, add whatever lipstick and holy water you need to get the essence of agile in the door, and call it whatever you want, and it will work.

Here's my suggestion for the problems, and associated load-bearing wall solutions:

  • Estimates will never be accurate enough, programmers are expensive, and must be highly utilized, therefore scope must be variable. All agile methods solves this by replacing scope definition and control with value optimization, in the form of an adaptively prioritized list of software capabilities.

  • Requirements conversations and valuation will always be error-prone, therefore feedback loops must be tight and clear. All agile methods solve this with frequent delivery of finished software.

  • Software design rots over time, therefore there must be a cost-effective way of controlling technical debt. Here's where XP prescribes TDD, pairing, and refactoring, and Scrum leaves it up to the team.

So, if in order to get Agile in the door, you have to give up variable scope, frequent delivery of finished software, or measures to keep the design clean, you've cut through a load-bearing wall and it will fall down. But if you have ways of doing these things, you'll do OK, regardless of what you call them.

See The Load-Bearing Walls of the House of Agile.

I think we need both by Steven Zhang

I feel only SCRUM is not enough for the software development. SCRUM only focus on the management side, focus on what needs to be done. But it does not mention let developer how to do it, where is TDD, pair programming, refactoring? They are very essential to build a good quality software but missing in SCRUM. So I think using XP on develper side, SCRUM on manager side.

Scrum estimation and velocity relies on a flat cost of change by Elizabeth Keogh

Scrum itself doesn't provide practices for achieving a flat cost of change. The feedback from a lack of flat cost of change can arrive too slowly to be spotted in retrospectives, and teams often lack the chance to catch up on any technical debt they produce in the early days.

XP provides some practices which flatten the cost of change. There are other toolsets that do a similar job. Velocity and estimation, though, need something like XP to be useful over the long term.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you