Don’t do XP

Steve Freeman offers a counter-argument on his blog entitled Do 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.

Throughout the 1980’s and 1990’s, as languages improved and lent themselves to better software design, the way people wrote and tested code changed.  In the OO community at large there was a slow, but spreading adoption of ideas such as continuous refactoring, limited responsibility, driving development through writing tests first (TDD), continuous integration, emergent design, the setting of coding standards and even pair programming.  What the XP movement (essentially Kent Beck and a few colleagues) did was to pull all these good practices together into a package, and bundled it up with the the Scrum patterns that Jeff Sutherland had been practicing at Easel Corporation since 1993.  In a sense, this was the first concrete implementation of the Abstract Scrum class [ref].

All of this is good.  But somehow the adoption of these practices didn’t explode as one might have imagined they would. Perhaps it was the name Extreme Programming; perhaps it was the chief, or loudest advocates proclaiming that this was the one truth; perhaps it was management fearing a geek revolution, and working hard to undermine the ideas.  Perhaps it was because, in the end, XP is just another methodology.  I don’t know.  I do know that very few software development teams in the world claim to be (admit to) using XP.

Scrum in the meantime gained enormous traction,.  Not always for the right reasons, of course, but nevertheless a good percentage of adoptions resulted in some improvement to the way software was being built.  And now the XP contingent want a piece of that pie.  They are hungry.

Firstly, lets be clear.  I am absolutely in favor of software development teams using the software development practices best known to produce high quality code leading to valuable products. Why on earth would anyone be opposed to that?  I am less in favor of dumping a package of 12 things on teams and prescribing a method of working that they must all follow. It flies in the face of “people over process” and the principle of self-organization.  In a good Software Scrum implementation the team members would discover good practices for themselves, and the adoption would become personal and meaningful.  That is the kind of improvement I seek.  That some Scrum teams have not yet discovered better ways of working means that the implementation of Scrum needs to be improved, not that team members should be told how to do their work.

Here’s my thought experiment: how many teams would have adopted all the good practices that XP recommends if XP never existed?  I believe many more.  I believe these practices would have come in a fluid way to individuals and teams, as they came to me as a craftsman who cares about what I make.  I have never “done XP” but I have certainly written quality software.  XP’s mistake is to insist on all-or-nothing adoption.  That may not be what the inventors intended, but it is how XP is perceived.  XP may be the cause of people not adopting good practice.  Ironic, isn’t it?

Another point worth noting is that the XP book was written about 12 years ago, since when around 40 new languages have been created [ref].  That means the XP advocates are recommending people use software practices that are potentially up to 12 years out of date — which is about one quarter the life of our entire industry. Scary.  Allow people to discover good practice for themselves and they may come up with practices far more effective than our best minds could produce at the end of the last century.

I urge Scrum coaches to stop talking about XP and start talking about software craftsmanship.  That is what we ultimately seek and desperately need in this industry.  Thankfully, there is now a software craftsmanship movement with its own manifesto [ref] which is slowly gaining support.  Finally, we can begin to reinvent our industry by following good craftsmanship practice rather than new, fix-all methodologies.

Developers: don’t do XP. Implement a common sense framework to surface all the dysfunction of years, to ground you in core human values, and within that learn to be craftsmen again.  Or get out of this industry.

54 responses to “Don’t do XP

  1. Pingback: Twitter Trackbacks on

  2. Hi Tobias,

    What do you think of the cultural values that underlie XP? ie:


    For me, these plus the practices were the thing that made XP work.

    I particularly like getting the practices implemented up-front because the feedback loops from not having a flattish cost-of-change curve can be so slow that developers don’t feel the pain of not having them for months – by which time it can be too late. I don’t like seeing people in pain, especially if that means overtime.

    • Hi Liz,
      Respect is a life value, not an XP value. Simplicity, Feedback, Courage all good, but I don’t see feedback as a “value”, rather a part of an empirical process. Communication is not enough, by far. We need deep collaboration.

      I am not saying XP is bad, I am just saying that the effort to get people to practice it over the past ten years has largely failed. It is time to re-think, don’t you reckon?

      • I’d say that the efforts to get people to practice Scrum have succeeded, and XP’s success can only be seen negatively if you’re looking at it as a relative measure. Scrum is much easier, and promises the same kind of successes as XP does. Adopting Scrum without the technical practices is like putting a contract out to tender and taking the lowest bidder. You don’t find out what the real cost is until later.

        I like “feedback” as a value just because “courage” doesn’t cut it enough, particularly where balancing feedback is concerned. Deliberately making the assumption that you’re wrong and seeking ways to prove it is completely counter-intuitive to the default human behaviour of model promotion.

        I agree with you about “collaboration” rather than “communication”. It’s interesting that Kent chose the second rather than the first, which I find more holistic. The values easily lead to collaboration anyway (especially when combined with Kanban 😉 ) so I’m not so worried.

      • I don’t understand your comments about value. What is a life value (certainly not everyone who lives values feedback)? How does that hold Respect from also being an XP value? Can I not value Feedback to the amount that it guides my actions when shovel comes to shove – and can’t it therefore also be a value?

        I agree that Collaboration is another important value, and perhaps it’s underemphasized by the XP literature. Not sure whether you want to imply that Collaboration implies Communication, or whether I would fully agree if so.

  3. Interesting perspective. I’m not a positive that many teams would have discovered XP-like practices just by themselves, though. Remember, a lot of teams which tried only some practices of XP then claimed that they didn’t work. Which presumedly was at least sometimes because they were missing support by the other practices.

    • Hi Ilja,
      I don’t disagree with you. It’s just that it is still a prescription, and that is what jars with me. How is it different from implementing full-on RUP? You could argue that RUP never works because people don’t do it “all the way” No?

      • Wrong. RUP was intended from the start to be tailored, i.e. pared down to fit the context. However, from my own experience I saw that the tool salespeople at Rational could care less about the process. Their agenda was to sell as much as possible, and adding tools upon tools to the suite drove those sales (I’ll have that extra shiny silver bullet, please!).

      • XP ist not a prescription, it’s a good starting point. “Start with these twelve practices and practice them until you really grok them and understand how they work together. Then adapt. If you adapt too early, you do so at your own risk.” Sounds reasonable to me.

        From the little I know, Dave is right, RUP is a process *framework* – you are supposed to tailor it to your needs *from the very beginning*, doing it “all the way” is most likely to kill your project. So, yes, there is a big difference.

  4. I think your points are good ones, and it’s hard to argue with success. A reasonable analogy is that Scrum is to Windows as Extreme Programming is to Linux. By focusing on market adoption and the lowest common denominator, Scrum definitely got all the market share. With Extreme Programming”s focus on excellence over approachability, it remained a polarizing niche product.

    In my work, I no longer mention either Scrum or XP except as a historical reference. My focus is on getting core feedback loops going, and then adding practices as needed to solve problems.

    However, if novices were asking me for one by-the-book approach to follow rigidly without a coach around (as that’s what novices often want) I’d still recommend XP. That’s because adopting generic Scrum can allow the buildup of large levels of technical debt before people realize what they’ve done. High technical debt is a giant barrier to further Agile improvement, limiting the long-term success of teams who naively take basic Scrum as sufficient.

    • Hi William,

      > My focus is on getting core feedback loops going, and then adding practices as needed to solve problems.
      I like this. Very simple.

      > if novices were asking me for one by-the-book approach to follow rigidly without a coach around (as that’s what novices often want) I’d still recommend XP.

      Does that actually work for you? I’d be amazed.

      • Well, I have limited data; the people who aren’t willing to get a coach are the ones I don’t hear much from.

        But it certainly worked for me. In 2000-2001 I tried implementing XP by the book. We got some of it right and some of it wrong, naturally. But having a prescriptive structure definitely set the bar higher than Scrum would have, and made it easier to see some of the holes in our process.

        I think my gradual-adoption approach only works with clients because I have a large catalog of symptoms and solutions, plus experience with a lot of shops. Without that around, I see teams plateau for long periods.

  5. I agree that people should now blame Scrum (“You can’t do Scrum without XP”). Also I think it is not so good to blame XP in return (“Without Scrum your process is nothing”).

    I don’t like all that buzz around “XP better than Scrum better than Lean better than your custom process”. I don’t like surveys about “Are you really doing Scrum” or “Are you really doing XP”. It’s all bullshit. There are SO many environment variables and processes are SO context dependent.

    You can’t generalize things like XP (or even Scrum). You should provide context first and clearly define zones where it work.

    Example. Iterations may be a bad approach for small support team. Pure flow may be good for small product development team.

    It’s all about context. As a trainer best what you can do is to come into new team, learn the context and adapt/improve dev. process, based on simple principles of agile manifesto, using ALL your knowledge about what works in what conditions.

  6. “Allow people to discover good practice for themselves and they may come up with practices far more effective than our best minds could produce at the end of the last century.”
    They may – or they may not. The teams I observed composing a set of practices all by themselves were by far less effective than those teams who started with THE TWELVE and evolved from there. XP is such a good starting point for most teams that not using it does not seem very craftsmenlike to me.

  7. Tobias,

    I agree that arguments about which “named cloud” is best XP or SCRUM are missing the point. I appreciate that your intent in this post is to encourage craftsmanship and I support your efforts in this. However, I feel that to encourage people not to try XP when you’ve never tried it yourself is quite strange.

    XP was the first agile methodology that I tried back in 2000 and I learned a tremendous amount from practicing it. Many elements are counter-intuitive such as TDD, CI, and pair programming. As soon as I came across SCRUM, Lean, and DSDM I embraced their complimentary practices by trying them too. I cannot agree that trying XP is a bad thing to do. I believe that you can learn at lot from trying XP.


    • Rachel, I wasn’t clear. When I said I haven’t “done XP” I was using the reference from my previous blog of “Doing Scrum” being meaningless.

      I have certainly used all the practices of XP, and I like them. There is nothing about the values and practices of XP that I dislike. I have also found that indeed they lead to better code, better value and a happier work environment.

      What I don’t like is the idea that Scrum or other Agile coaches have to tell teams to “do XP”. It is counterproductive.

      Focus on the practices, not the methodology, that is my message.

      • Novices like step-by-step practices that they can try out. XP has a bundle. From that perspective, it isn’t counter-productive – just a good starting point. It’s worked for a number of teams I’ve been involved with.

        How do you define “focusing on a methodology”, anyway? For me, it’s always been about the people, then practices, then tools. The named methodology is just an anchor; a label for getting hold of related resources, stories and ideas. This seems true for any methodology (including Scrum!)

  8. The biggest problem with XP1E as it was applied was that XP was something only programmers could do. If you were not someone technical, XP did not speak to you. If you look at XP2E, you can see Kent tried to fix that problem\misapplication. Scrum on the other hand, allowed everyone to participate and I believe that is why there is greater adoption of Scrum.

    As an interesting side note, around 2000-2003 XP had a lot more mindshare than Scrum with people observing our community from the outside. To outsiders, XP looked ascendent. Look at software engineering, estimating and requirements books published in this timeframe and in many you will find discussions about “Agile alternatives” referring to Extreme Programming. Scrum is only mentioned in passing – what a difference a few years makes.

    BTW – I came to Agile much like Rachel, I worked on an XP project and got hooked. My main problem was no one would let do XP, so I got interested in the other practices.

  9. Summary: in the nineties there were a lot of good ideas. Someone “bundled” these ideas into XP. Recommending them as a “bundle” caused people not to use them. If no one had done that Scrum teams would have figured it out for themselves. Also, they would have figured out something better.

    XP is like marijuana. It will make you stupid, stunt your growth, get you pregnant, and cause you to murder your neighbors. You will never get a job and you will die alone.

    How about this: Scrum beats XP because no one has ever claimed you could pay them $1,000, sit on your ass for two days, and “Master” the latter.

  10. Pingback: Don't do XP « Agile Anarchy « Improvers

  11. Stefano Ricciardi

    I am with Johannes here. Had it not been for XP in the early 2000’s, I would have not come across all these practices bundled together.

    I have started from there and then kept the practices that worked best for me and the team (having a customer onsite was a no-no, and also pair programming didn’t quite work in our environment).

    I have never felt XP imposing a all-or-nothing approach to it’s process, but then again I have learned XP mostly from books and publications as opposed to evangelism and conferences or coaches.

  12. Tobias, thanks for this post. I agree with you about the main point: Do not throw 12 practices on a team and say: “Follow this”. When I last introduced Scrum to a customer, I introduced it practice by practice, whenever a development process problem popped up in the team. E.g. “Hey, we cannot keep our promised dates!” –> let’s do proper planning using story cards and planning poker. Or: “Oops, our requirements change almost randomly” –> let’s define a product owner, have him create a prioritized backlog and keep it constant for one sprint, then allow to adjust.

    On the other hand: XP with its 12 practices forms a very special system with a basic idea behind it. I found it most useful to explain this basic idea to the team and establish a gut feeling for it, first, and then go practice by practice, as the team sees the need.

    So, I would never say “don’t do XP” but I’d rather say: “Look here: Other people have done XP successfully. Let’s see why it is so special and let’s see what we can learn from it.”

  13. I’m very disappointed with this post. Not least because you’re rejecting out of hand something you’ve never tried.

    I think you’ve forgotten just how far we’ve come in the last decade. That we have a craft movement at all is because XP put the actual writing of code back into the centre of the discussion. Just look at who’s involved, it’s the same people. I think you also forget just how counter-intuitive many of the XP practices are, especially compared to the direction the industry was moving at the time.

    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.

    And what’s with the paranoia about the hungry “XP contingent”? Most of them are in the Scrum Alliance collecting training fees.

    I’ve responded more fully at

  14. Pingback: Paircoaching’s Weblog

  15. @Ilja
    > Start with these twelve practices…
    That’s the problem, how do you start doing 12 new things all at once without being overwhelmed? This is exactly the reason XP hasn’t taken hold more widely. Most companies don’t even have teams, so they form then. If you form a new team and say now you must use these 12 practices you can imagine there will be resistance. And how can you say it is not prescriptive? It prescribes 12 practices and says you must do them all.

    I prefer to let teams arrive at better practices in their own time. Of course I guide them towards pair-programming, TDD/ATTD, continuous building and refactoring and I introduce task boards and story points. But this is not “doing XP”. The practices are brought in one at a time, as the team feel ready to adopt them,

    • One of the most pleasant experiences I ever had was with a newly formed team, where everyone knew from the very beginning that we where supposed to do XP. It was a two week training project with two day iterations, and we had a great time, while being able to turn on a dime.

      After that project, we got distributed over several other projects, most of them more scrumish. Or, as one of my former teammates liked to say, they were doing something “almost, but not totally, unlike XP”.

      • Ilja, perhaps your experience is the exception that proves the rule 😉 I don’t contend that there is no value in XP. Of course there is! But is it not a concern that XP still only exists in a small niche market? The practices and values of XP are wonderful but people are not willing to go down the long, 12-practice pathway. It is a very big commitment for so many organizations. Instead, introduce these practices as they are needed (i.e. aligned with the team’s feedback. This I believe, will be a more effective way of guiding people towards XP.

        I keep repeating myself but here goes again: I like XP. XP works. I have a lot of respect for Kent Beck for bringing this forth. The title of this blog was intended to be provocotive. We all get complacent. “Do XP” is a quick fix for coaches, as they don’t need the teams they are working with to think for themselves, or become creative and inventive. It begins to feel like just another silver bullet methodology — which is tragic. All I ask is that we find alternate ways of getting to good practices. This course of action feels more aligned with the values of trust and respect.

  16. @tobias It must all depend on context. XP is a carefully balanced set of practices and some teams will just go for it–I’ve certainly seen it. After all, if you’re forming a new team you can make sure they’re volunteers. The biggest risk is that they’ll annoy the rest of the organisation which will take its revenge.

    Other teams need a slower path, particularly if they’re already established. But most people who have no relevant experience don’t know how to make the trade-offs for the practices they’re missing–obviously, since they’ve never seen it.

    The great advantage of just going for XP is that at least you know what you’re aiming for. It should also be cheaper. It cost my employers a lot of money for me to learn the advantages of skills like encapsulation and modularity (and I see plenty of places where they’re still learning). If I could have done it faster we would both have benefitted.


  17. Perhaps, you should not say, “Do all these twelve things at once, immediately.” I don’t know anyone who is saying that. There probably are some people who have said that, but people say dumb things all the time. Don’t blame XP.

    What does it mean to do XP? If you are doing Scrum you are already doing the Planning Game, Small Releases, and your “cross-functional team” is a Whole Team (including the PO.) If you are also doing TDD then you are doing Test-First Programming, Simple Design, and Refactoring. If you are doing Continuous Integration then you are also practicing Collective Ownership and you probably have a Coding Standard. All that is left is to add Pair Programming, Metaphor, and Sustainable Pace, and you have all of the original practices.

    None of the XP literature suggests that you have to start doing all of these things right away. So, if you get to the point where you are doing Scrum + TDD + CI, which a lot of Scrum folks see as the gold standard, then you are doing the majority of XP.

    Saying that you should do all these things but “don’t do XP” doesn’t even make sense. Not calling it XP is disingenuous (I’d go as far as to call it stealing.)

    • Adam, there are a lot of ifs in there. Most of the teams I work with have years-old legacy code, a hero culture, QA in India and everyone isolates themselves in cubicles. “Do XP” just won’t fly in such environments. Starting with some coding standards, automated testing and pairing to share the over-protected knowledge is about as much as I can hope for during the first few months.

      Pairing + coding standards +autoQA does not equal XP. If it wasn’t clear in the post I’ll say it again: I have nothing against the XP practices, but lets take them on individual merit, and not always believe we must do all of them. There’s such a thing as context, and XP is not a silver bullet.

      XP has so little traction except amongst an elite few that it is time to reframe those practices in a different way. After all, we want developers to adopt them.

      • We certainly have very different perspectives. For example, I’ve never seen a cubicle other than on tv.

        I also don’t care very much about teams that are ok with being mediocre. I don’t care about spreading Agile as wide (and consequently thin) as possible. I care about finding teams that passionately want to become excellent and working with them.

        Response: Ilja, your experience is the exception that proves the rule 😉 I agree that if you have a new team of developers, with little experience that is a great opportunity to evangelize XP. But the majority of software companies I have worked with are decidedly still working on code that is 10-15 years-old spaghetti code of which they are very protective. Bringing in XP with all its counter-intuitive practices causes managers to reel. Reeling managers are unable to make informed decisions, and are likely to fallback into their comfort zone.

  18. Perhaps it is a limit of the English language, or my mastery thereof, but I thought the “ifs” were fairly strategic.

    What I am saying is that 1) I don’t believe that XP is all or nothing or needs to be adopted some specific increment at a time. 2) I believe, fundamentally in giving credit where credit is due at least where I am well informed and able. Certain practices belong to XP.

    When possible, I will even attribute individual ideas to individual persons. I am not Ken Schwaber’s biggest fan, but I give him credit for the ideas he claims to have invented. How can you justify doing TDD or CI or Pair Programming without naming Kent Beck and Ward Cunningham and Ron Jeffries, etc? How can you do any of those things and deny XP? Do you contend that those people had no influence over the way you do/coach those things?

    • Adam, you make an assumption that I don’t mention XP in my classes or to my clients. I do, and I am happy to, but more often I refer to particular practices.

      And, I don’t know for sure that the people you named invented that stuff. I worked for a company in 2002 that used all of the practices you mention, plus continuous refactoring. I was the only person familiar with XP and I certainly didn’t drive those practices. They occurred because they were the right thing to do. Emergent solutions, you see.

  19. 2002 is post Snowbird and post C3,

    It’s not just about “invention”. Ken and Jeff didn’t “invent” Scrum. Takeuchi and Nonaka did. It’s about attribution, where did the ideas come from?

    If there is any possibility that some part of how you practice software development originates with the C3 folks, and you deliberately avoid attribution, then you are plagiarizing them, by definition.

    The title of your post is “Don’t Do XP.” That is cute, but disingenuous, because you don’t actually mean “Don’t do the things that constitute XP.” At a minimum you are being flippant and I take exception to that in this context.

  20. Adam, I actually mean Don’t do XP. The practices are valuable, but I believe the name has prevented it from spreading. Perhaps if we just used the term ‘software craft’ there would be a greater adoption. I want to see good practice adopted, and in the end it doesn’t matter where the ideas came from, and once again, C3 or Kent Beck didn’t invent these practices. Most existed, and were packaged together in an excellent way. Although, I believe it is the package that prevents adoption. Which is too bad.

    > 2002 is post Snowbird and post C3
    Yes, I know that. No one in our team back then (including me) was familiar with those references, nor with the XP literature. Still, we used the practices.

  21. The objection to the name “Extreme Programming” has been there as long as I have been around. I have to admit that I don’t understand it. We mostly seem to agree that these are the right practices so why is the name so important???

    Kent, Ward, et al claimed that they didn’t invent the practices but they just rediscovered them. Nonetheless, TDD (and BDD) as we now understand them are evolutions above what existed before and that comes out of the XP community. Same is true of CI, ATDD, and Pair Programming (at least).

    If you have some independent evolution based on some prior art I would love to hear about it. I don’t buy it, though. I think you just don’t want to give credit, and I can’t help but question the motivations behind that.

  22. Adam,
    > I think you just don’t want to give credit, and I can’t help but question the motivations behind that.
    Your thinking is misguided. I give credit where credit is due, but I focus more on the principals, less on the personalities. I wonder why you are taking this personally and speaking on behalf of others. If they cared, people like Ron Jeffries would be all over this. My blog post is not a put-down of XP, and I think that is apparent to most.

    > If you have some independent evolution…
    I don’t know where the developers got their ideas from, but almost certainly it wasn’t from the XP book. Just some smart people trying to solve the problems as best they could. It was an exceptional team.

  23. I am not speaking for anyone else. I am speaking on principle, and I am taking it personally because I think you are a mostly reasonable guy who I would like to have a beer with some time, but I find your position indefensible.

    I know that test-first, simple design, and refactoring preceded XP. I don’t buy that your team derived TDD from that independent of the XP community. So, either you don’t know what you are talking about (Which I don’t believe) or you are not willing to call a spade a spade (Which I don’t understand.)

  24. It was not TDD as the term is understood now, but I have always been very test-obsessed, driving my deigns through experiment, and testing at the acceptance level continuously. Other team members saw the value. We didn’t have a test framework for unit testing, and I’m not sure we knew such a thing existed.

    You can continue to make assumptions about me, if that brings you some sense of satisfaction. This conversation has reached a dead end though. Please feel free to have the last word.

  25. Pingback: – Don’t do XP

  26. Doesn’t XPE even have a chapter on piecemeal adoption?

  27. I don’t see how doing XP can be a valid excuse for not thinking for yourself. People who do that will probably do the same with Scrum. I’ve actually seen similar behavior with Scrum proponents.

  28. I’ll throw in 2 cents here…

    I think it is valuable to have a container of great practices. Implement them all at once if that is best for you preceisely as said in the book or implement them in ways that work for you incrementally. Sometimes it is best to follow the recipe to understand it and then move to tailoring it for your family’s taste so to speak. (I.e. tak Scrum or XP as a prescription first then realize the values of the practices and tailor it to what works best for the team.) Hopefully in the end you are doing what you are saying Tobias, simply implementing sound software craftsmanship.

    Thanks for the great controversial article!

  29. Four things:

    1. I distinctly remember discussions involving Kent Beck on the mother wiki in 1999 in which he was advocating incremental adoption of the XP practices to solve your worst problem first

    2. Ilja’s experience is not the exception that proves the rule, unless Ilja’s experience and mine are the two exceptions that prove the rule. You should probably add Steve Freeman’s experience to that list of exceptions too. It behooves ill of you to dismiss that experience out of hand in the way that you have.

    3. Short, timeboxed iterations, (which I am profoundly in favour of until the team has learned enough discipline to move to a more fluid approach, should they want to) are a central premise of Scrum, but are about as different from what I find to be common practice as it is possible to be (most of my work is in investment banks) and are quite often perceived to be about as prescriptive as you can get.

    4. Your ‘thought experiment’: I agree with you in the same way that I believe that people will suddenly no longer need to believe in a god, i.e. not at all.

    My approach these days is pretty much as William Pietri describes.

    I agree with you that we can do without the ‘you must do XP when you do Scrum’ brigade, but quite frankly, I can do without the provocative ‘Don’t Do XP’ title too.

  30. Hi Tobias,

    Its true that Scrum won out in the popularity stakes, but isn’t that part of the problem? As practitioners shouldn’t we care most about what works, where, when and why rather then what is most popular? As “snake oil” salespersons and the purveyors of the latest fad, then of course popularity and eager new adopters is indeed important 🙂 But don’t we want Agile to be more then just the latest passing fad?

    Perhaps we should be doing less selling and letting the work of successful practitioners speak for itself?

    You obviously have a deep understanding of Scrum, many don’t though, and Scrum leaves out lots of important detail and guidance that XP provides.

    As a budding Agilist you’ve got to serve your apprenticeship somewhere and I would put XP on the top of my list of places to start. Obviously over time you’ll inspect and adapt and pull stuff from where ever.
    I agree with your assessment of the Craftsmanship movement as a positive, as it moves us beyond methodology and branding. An interesting observation though, is that people who cut their teeth with XP tend to be amongst the best Agilists out there, even though Kent et al did the least amount of packaging and selling (bar a few books).

    Food for thought.


  31. Pingback: Yasodara Córdova - [status]

  32. Pingback: Yasodara Córdova status on Thursday, 22-Oct-09

  33. Pingback: The Storming phase of the (agile) IT world « Yves Hanoulle

  34. It’s been noted that XP is 12+ years old.

    However Scrum is even older than that; in fact Scrum eschews modern technological advances like email, telecommuting, remotely located teams, large teams, etc. Talk about backwards!

    What are your thoughts in terms of Scrum being retro, not just XP?

    What are your thoughts on the many pointless rituals and ceremonies in Scrum that are more process than people oriented?


    • I don’t see the ritual aspect of Scrum (or XP) to be pointless, rather I believe that ritual in our lives, at work or anywhere is vital to a sense of purpose and peace. Ritual gives us rhythm and focus. Group/team ceremonies create fellowship. If the “rituals and ceremonies” of Scrum, as practiced, are seen as pointless, I suggest you are missing something vital. Scrum works exactly because of its rituals, not in spite of them, and certainly not without them. And Scrum, practiced wholeheartedly, really does work.

      • Hi Tobias,

        Over the last couple of years I’ve come to understand your position on Scrum a lot better. I understand we also focus on slightly different aspects of Scrum here in the UK.

        One of the things which we seem to focus on a lot here are estimates and velocity. They’re two things which, if they’re going to work for planning releases, rely on a flat cost of change curve. To get that flat cost of change requires some technical practices to keep change low, and I think that’s where a lot of my own “XP wins” is coming from.

        Do you have a post somewhere which calls out which rituals you value from Scrum? Do you value estimation and velocity, or is it more about the team’s empowerment and ability to commit to something sensible? What do you do about things like good technical practices, the lack of which doesn’t get felt for a while, but then gets felt very heavily later? Do teams naturally adopt these once they have that safe space to practice in? Are there some rituals you value more than others?

        Answers in a blog post please (or feel free to link anything you’ve already written!) Looking forward to whatever you choose to write next.

  35. That’s a standard answer. “Everything in Scrum — even the pointless rituals — are vital”.

    So is there anything you think needs to be changed or questioned about Scrum or is it basically perfect as is in your opinion?

    FYI I don’t think I’m missing anything “vital” about the process in fact I plan to blog more about the subject in depth.


  36. Hi Liz, I meant to reply at the time you posted your comment, but got side-tracked… you know how that goes =]

    I don’t value estimation very highly at all, it is merely an interim (and temporary) step towards meaningful commitment. And I only focus on velocity as a side-effect of regularly producing work, and then only at a fairly coarse-grained level, i.e. number of requests (stories) completed per agreed time interval.

    The ceremonies I am referring to are the planning session, the daily standup, the review and the retrospective. Doing these meetings regularly and consistently creates the rhythm of Scrum, which is vital for surfacing organizational dysfunction. I see each meeting as having a specific purpose… Understand & Commit, Align towards a Goal, Inspect the Product, and Inspect the Process. Each meeting is a necessary dialog towards the goal of continual improvement, which itself results in effective, carefree teams creating awesome products and services.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s