Google+ Followers

Friday, January 21, 2011

Scrum has 3 advantages over XP (but XP is better)

For corporations Scrum offers three advantages over Extreme Programming:

1) It offers certification - corporates can hire people who are “certified” and have their own people certified.
2) Scrum traces its roots back to the Harvard Business Review - so it must be serious
3) Scrum does not contain the words “extreme” or “programming”. No need to dirty our hands with messy code, keep that stuff as far away as possible (the further the cheaper, right?)

On the other hand, XP has two advantages over Scrum:

1) It actively seeks to address the quality problems most software development teams suffer from and which cripple productivity
2) It excites the people who actually do the work - dispensing with “resistance to change” in one fell swoop

At Agile Cambridge last year I saw a really good presentation from people at GE Energy about their Agile adoption. Frankly I’m sceptical about the ability of any large organisation to adopt Agile but these guys had some real success to show.

Two things stuck in my mind. When summing up the presenter said:

“If I was doing the same thing again I would start with the XP technical practices not the Scrum process” and he went on “We have adopted Scrum, we are now advancing to XP.”

XP and Scrum date from about the same time (mid-90’s). Perhaps because XP become popular first and Scrum later succeeded it as the Agile-poster-child many people seem to think Scrum is superior, or at least a superset of XP. Actually, the reverse is true.

XP is a superset of Scrum, and, in my humble opinion, superior.


10 comments:

  1. Sutherland did say in a speech that Scrum works best with XP

    ReplyDelete
  2. I too thought Jeff had said that at his ACCU London talk back in May 2009. In fact here's a quote from my review for C Vu :-)

    "Jeff started with a brief introduction to what Agile Development is, along with a look at the core values from the Agile Manifesto and some of the other Agile Methods such as eXtreme Programming. However, rather than just listing XP as another methodology, he actively promoted the use of the XP technical disciplines such as TDD and Pair Programming. This was highlighted further in a later slide that discussed a more symbiotic relationship between Scrum and XP."

    ReplyDelete
  3. Other than your useless five points above (the two for XP could also be said of Scrum), what are the other main differences between XP and Scrum?

    You make some bold statements, but are't backing them up with examples. It makes it difficult to form an opinion when there is no tangible data to do so with.

    ReplyDelete
  4. Mike, nice to have your comment, sorry you didn't like my post.

    The main difference between XP and Scrum is not a question I set out to answer, thus you won't find the answer in the post. And I don't think this is a question you actually need me to answer, I think you know the difference.


    Bold statements: Yes
    Evidence: None, its all opinion derived from experience. If you want evidence go read some hard research, blogs are not a place were you find much of that. A quick look at your blog and I don't see much hard evidence either. That's blogging for you, its why we love it and why we hate it.

    ReplyDelete
  5. Allan, thanks for stating so boldly something that has become an unspoken truth in the agile community over the past few years.

    Based on recent experience, I've talked about how the Scrum presumption that a self-organising team will automatically adopt XP-style technical practices is foolhardy. XP-style practices are mandatory in XP, not implicitly encouraged as in Scrum, and I'd argue its emphasis upon technical quality is baked in.

    I'm sure you're aware that Martin Fowler coined the term <a href="http://martinfowler.com/bliki/FlaccidScrum.html>Flaccid Scrum</a> for this very problem.

    ReplyDelete
  6. Allan, thank you for saying aloud something that has become almost an unspoken truth in the agile community over the past few years.

    Based on recent experience, I'd strongly agree with you that Scrum suffers from a lack of focus upon technical quality. For me, XP is superior because that focus upon techncial quality is baked in, rather than implicitly encouraged.

    I've seen plenty of well-organised Scrum teams end up in a hopeless tangle - in fact, Martin Fowler has a neat term for this, Flaccid Scrum.

    ReplyDelete
  7. I must admit that now-a-days I'm mostly a Scrummer.
    This controversy has limited use. I sympathize with your views; however each community (XP and Scrum) has learnt from the other; XPers started stand-ups and retrospectives; Scrummers user stories etc.... They can learn more from each other, it's just that Scrummers have tended to learn more (maybe the need was greater); Also the thought leaders in this community are increasingly insistent upon technical competence (and rightly so). However XPers can learn more from Scrum. This hasn't happened a lot and is unfortunate. Do pay attention to the very last sentence of Mr Fowler's article, Bond. There is more depth in Scrum than you think. I appeal and urge that XPers take a closer and more careful look at Scrum. Having said that, I strongly suspect, that the three reasons, you mention at the beginning of your post, are largely true; and beautifully written, the innuendo pointed!

    ReplyDelete
  8. Nice summation. My only gripe with (the execution of) XP is misuse of the practice of pair programming. Some kinds of work can involve too much learning at too deep a level for pairing to work ... it interrupts the cognitive patterns of the deep learner, and if the other 1/2 pair is not a good coach, not recognising when to back off and let the neural magic happen in their partner's brain, it leads to friction and breakdown. Always consider that deep learning tasks are not good tasks for full time pairing, and that what is deep learning depends on the current experience and capabilities of each 1/2 pair.

    ReplyDelete
  9. !An agile process tends to focus on iterations, and client feedback, to allow for the inevitabilty of changing requirements whereas a waterfall process tries to define all requirements up front, and tends to be inflexible to changing requirements. You can learn more about agile and scrum by referring to some free resouces (http://www.scrumstudy.com/free-resources.asp) provided by scrumstudy or by attending any agile scrum certification courses. I would personally suggest Agile Expert Certified course or Scrum Master Certification to you.

    ReplyDelete