Scrum is fine, but don’t leave the XP at home

Don’t read this post as a criticism of Scrum per se, I’m just concerned that the popularity of Scrum is somewhat watering down the Agile movement. 

The last couple years I’ve noticed a huge uptick in interest in Scrum and far less mention of Extreme Programming.  When Roy Osherove did his Hot/Not Hot list, Scott Hanselman even commented that Scrum was HOT while XP was NOT HOT.  It’s not hard to understand why Scrum is more successful now than Extreme Programming and XP’s somewhat scary (or goofy) terminology and undeserved reputation for being hackery.  Scrum has always been more conscious (or conciliatory) of its image in corporate settings and benefits from the strong focus on project management and now portfolio management.  All the same, I think it’s somewhat unfortunate because there’s still so much good stuff in XP that’s lacking in out of the box Scrum*.  Specifically, XP has its roots very firmly on the software engineering side of things while Scrum is primarily a project management practice.  You’ll see this evidenced in practices like simple design, TDD/BDD, Continuous Integration, and the strong emphasis on testing.  While Scrum might have a better, or at least more palatable, story for project management, don’t leave the engineering practices from XP behind.  Scrum does provide a nice framework for iterative project management, but all those engineering disciplines from XP are built specifically to enable rapid iterations.  In a way I think Scrum is dessert and XP is the broccoli in your diet of software practices. 

Of course, in another way the interest in Scrum is very healthy because it’s bringing project managers and non-developers into the Agile fold.  The effectiveness of my XP engineering practices is magnified when the rest of the team is working iteratively to support my development and testing practices.  The common practice of developers working iteratively and adaptively within a team of waterfall-ish project management and testing is always an unsatisfying compromise.

 

Unsurprisingly, Scott Bellware had something to say on the subject as well.

 

* Most Scrum teams I’ve run across adopt XP engineering practices anyway.  Maybe not as rigorously as the early XP teams, but they do eat their broccoli too. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.hasith.net Hasith

    Came across your post through some search in Google. Really nice post and is written in 2007. You had visioned the chaos much earlier! Really true that many of the companies just start with Scrum thinking it will solve the problems they have. What they dont realize is that the successful Scrum adapters had engineering practices already well in place. This was actually a subject I discussed couple of months ago in one of my posts too (http://blog.hasith.net/2009/12/when-to-scrum.html).

  • http://mattwynne.wordpress.com Matt Wynne

    I totally agree, though IMO scrum is the plate, knife and fork, and XP is the brocooli.

    You could still eat the brocolli and get a decent meal, but if you wanted to show what you were doing to the board, you’d probably want to use cutlery!

  • http://flimflan.com/blog Joshua Flanagan

    In my experience, it is much easier to promote changing a process when people are feeling the pain of the current process.
    Scrum can be very attractive to a team that knows the pain of a waterfall process. However, since they’ve been coasting along in a bogged down waterfall, they don’t yet feel the need for XP practices.
    Once the team starts practicing scrum, they start feeling the pain of not having XP practices to support it. This makes XP adoption much easier. As Mike says, the team “invents” the practices they need to work within a productive scrum. The team now feels empowerment and ownership, because they helped come to the conclusion of what was needed – as opposed to being told by someone else to eat their broccoli because its good for them.

  • http://www.mountaingoatsoftware.com Mike Cohn

    I completely agree about the importance of adding in the XP practices. I like to start with Scrum then encourage teams to “invent XP” by figuring out what engineering practices they need to add. Hopefully they adopt just about all of XP’s. Many, but not all, get there.

    As a long-time Scrum guy, what I find quite amusing is the discussion of Scrum being easier to sell and easier to introduce. This may be true but it’s a long way from the late 1990s when half the time I’d introduce Scrum without using the words (it is a rather weird-sounding word, even if you know what it means). Ken Schwaber says Scrum has a “vocabulary of change”, meaning that words like ScrumMaster, product backlog, daily scrum, are meant to be so different they shock our ears into noticing that something is different.

  • http://dotmad.blogspot.com/2007/09/xp-and-scrum.html Adi

    Scrum is hot because it’s easier to adopt as a complete system:
    http://dotmad.blogspot.com/2007/09/xp-and-scrum.html

  • Kevin Thex

    Love the practice of XP, but having poorly implemented it for a year, it really only seems applicable for conscientious, experienced developers.

    When working with some of the archetypes you listed in a previous post (where’d it go?), plus the “Science Fair Guy”, the “Svengali & the Svengalettes”, the “Sand Baggers”, the the “Saboteurs”, not to mention other teams (who seem to have a disproportionately larger number of those types), it was incredibly difficult to hold individuals accountable.

    We just started SCRUM and are in our first iteration. A team member came to me last week and asked why another team member had only contributed 3 days to the burn down chart (we’re in day 10 of 15).

    I’ve tried a number of different approaches over the years, but I have never had a member of the team come to me and be able to objectively quantify the negative impact of a poor performer. Because we had all planned and estimated the work together, the subsequent “counseling” was tremendously streamlined by not having to play the “No I’m not / yes you are” game.

    It gets the PM’s and any one else who wants to drop by and ask “how’s it going” off my back. It delegates ownership of team deliverables to the team. All of this is good for me, because now I can get back to messing up the code.

  • http://www.jameskovacs.com James Kovacs

    Having had experience “selling” both Scrum and XP, Scrum is definitely the easier sell. Scrum replaces one set of ceremonies with another. Longer meetings (weekly status meetings) are now daily stand-ups and sprint reviews. A lot of “Scrum” teams run in a Command & Control style with the PM allotting tasks. (I know that’s not how it is supposed to work, but it’s hard to turn a PM into a Scrum Master.) Overall Scrum has marginal impact on how the team works. On the other extreme, XP changes how you approach development in a very profound way. It questions the way you’ve been working and solving problems. A developer lives and breathes XP every minute of every day. Most of the time, you can forget that you are using Scrum. You can’t forget that you’re doing XP until it becomes so second nature that you can’t imagine doing anything else.

  • http://blogs.solidhouse.com/david.woods Dave Woods

    I think why scrum is HOT is because it is a much easier sell to higher ups. It has process and it is easy to see connections to your existing process. It is a bit easier of a change than going from hard corporate structure to the perceived looseness of XP.