InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Do Extreme Programming Folks Care about Scrum?

Posted by Vikas Hazrati on Apr 02, 2008

Sections
Process & Practices
Topics
Agile Techniques ,
Agile
In a raging discussion on the Extreme Programming group Michael James started a discussion on whether Scrum is alienating Extreme Programming folks. He suggested that till date he had thought that XP and Scrum were allies but some members of the group had different thoughts.

Simon Jones suggested that though he is not anti Scrum but there are a few questions that spring up
- I do struggle to see what one gains from Scrum (apart from more effective marketing) that is not readily provided for in XP?
- Scrum feels like a project management related subset of XP.
- I've never been sure why Scrum /intentionally/ avoids detailed recommendations on engineering practices.
- A little knowledge can be a dangerous thing. Scrum either seems to give enough guidance to be more agile... or enough rope to hang yourself with.
Some members in the group who were supporting Scrum suggested that many XP ideas were actually based on Scrum since Scrum predates XP.

Seyit Caglar Abbasoglu sparked the discussion with his thoughts, he mentioned
I believe those engineering practices are the main part of XP that fears aged managers. It seems like Scrum guys are hiding them until they have the opportunity to show why they are needed and how they are useful. I'd not be surprised that some of those practices to be added into Scrum after they become industry standards.
Alistair Cockburn said that comments like these are alienating the Scrum folks. He added that practices of XP though "useful" are not "necessary" for a project to succeed. Other members countered that they had been on projects where Scrum was being followed without XP and eventually they had to introduce XP practices to make the project succeed. To this Alistair responded by citing example of a company where Scrum was being used without XP and the project was successful with happy customers. He also mentioned another project where Crystal was being used without XP and the result was positive.

Alistair further reiterated that he considered the XP practices useful but not necessary
The question would then become, to what extent are TDD, pair programming, possibly continuous integration, possibly on-site customer sitting between "nice" "useful" and "necessary".
I'll argue that they are useful and not necessary.
J. B. Rainsberger however attributed the success of the teams who succeeded without XP practices to talented, thoughtful and knowledgeable team members on the team. As per him the Scrum practitioners who are not advocating XP practices are not working in the interest of average development teams who do not have above average talent and cannot succeed without proper engineering practices.

The group did not seem to agree either way on whether Scrum can work without XP or does it need XP to fill in the void on engineering practices. Some people however did mention that they had used a combination of both pretty successfully on their projects.

10 comments

Watch Thread Reply

Been happily using Scrum sans XP by Jim Leonardo Posted
Re: Been happily using Scrum sans XP by J. B. Rainsberger Posted
It's all about self-directed teams by Bruce Rennie Posted
After further reflection... by J. B. Rainsberger Posted
Re: After further reflection... by Bruce Rennie Posted
Using Scrum without XP by bruce Robinson Posted
People Over Processes, Change Over Plans by Wayne Mack Posted
Re: People Over Processes, Change Over Plans by Vikas Hazrati Posted
Pointless marketing-driven bandwagon by James Richardson Posted
Any approach can succeed... by Andrew Walker Posted
  1. Back to top

    Been happily using Scrum sans XP

    by Jim Leonardo

    We've been using Scrum without using XP and there's been few problems that have come up that XP itself would have solved.

    I agree wholeheartedly that Scrum is not a development methodology, its a PM methodology. In fact, we've been using it effectively for non-programming groups, so I think that pretty much puts the nail in the coffin of "it needs XP".

    ALL projects require taleneted, thoughtful, knowledgeable team members. XP, RUP, Crystal, etc can't help you when you have a crappy team. The only thing they can do is help put enough controls in place to limit the damage.

  2. Back to top

    It's all about self-directed teams

    by Bruce Rennie

    Scrum, more than anything else, is about creating teams that solves their own problems. What kind of a message would it be if you said "Hey, solve your own problems" and then proceeded to list a series of practices that MUST be used in order to follow the methodology. Doesn't make sense.


    Sure, its possible that most Scrum teams eventually decide that adding XP practices makes the most sense. That's not the point. The point is, THEY decided to do it.


    And yes, it's possible to get into a lot of trouble if you think that Scrum alone is enough but that sort of thinking will get you into trouble no matter which methodology you use, including waterfall. In case no ones noticed, XP itself is often criticized for not prescribing a lot of practices that others deem necessary.

  3. Back to top

    After further reflection...

    by J. B. Rainsberger

    I've thought about this more, and I wish to refine my position. While I agree that teams ought to discover their own low-level process, most teams I meet don't know about the XP practices well enough to know when to try them. This is why I expose them to these practices early. It's as though they need a few such practices to start, while they also learn how to inspect and adapt, in the Scrum spirit.

    When I read this article, my words didn't mean to me now what I wanted them to mean when I wrote them.

    The talent and knowledge I meant when
    I participated in the thread related to critical thinking kinds of skill, and not programming skill. I hope that clarifies things.

  4. Back to top

    Re: Been happily using Scrum sans XP

    by J. B. Rainsberger

    The more a team is skilled at making good decisions, the less direction it needs. I believe the opposite is true. In that sense, any process can help, and XP seems best suited to fit with Scrum.

  5. Back to top

    Using Scrum without XP

    by bruce Robinson

    Scrum doesn't define the engineering practices, but so what. It doesn't require XP, nor does it prohibit XP.

    Some of the comments suggested that engineering practices are required for success. I completely agree, I just don't assume that XP practices are the correct ones for all situations.

    I have successfully adopted Scrum to my team and we follow some pretty standard practices like code inspection rather then pair programming. I have seen more benefits from Scrum then I have with just XP.

  6. Back to top

    Re: After further reflection...

    by Bruce Rennie

    Sure, this is why XP is deemed such a "natural" fit for Scrum. You almost certainly need some developer practices. If you have to start somewhere on your "inspect and adapt" journey, XP practices are as good a starting place as any.



    I also agree with you on the talented and thoughtful/critical thinking part, but have to point out that that type of team is far more likely to understand that they need practices in the first place. Agile methods really do crank things up to 11: a clueless team will crash and burn in spectacular ways not possible with a good old waterfall approach. On the plus side they'll likely to it a lot earlier.

  7. Back to top

    People Over Processes, Change Over Plans

    by Wayne Mack

    I think we need to go back to the basics of agile and focus on valuing people over processes and change over fixed plans. Scrum is good; XP is good; neither is the one true way.

    XP provides a lot of good development practices.
    An XP Planning Game and a Scrum Planning Meeting seem extremely similar.
    A Scrum Sprint Review and Sprint Retrospective seem to be good additions to the XP cycle.
    Neither approach seems to address scaling to a significant degree beyond saying "Conquer then divide" or "Scrum of Scrums". Neither really addresses how to determine "customer value" or how to initially size an effort. There are lots of adaptations and extensions that are needed, so why bother arguing one versus the other?

    I am a firm believer in the chinese menu approach. Learn both Scrum and XP and pick what is feasible for your environment, for the current set of people you will work with. As people learn more, they may choose more items. You may never be "pure", but you will continue to improve. Finally, there are still missing items on that menu, so you may need to go next door for french fries or make your own salad. Be adaptable, be agile.

  8. Back to top

    Pointless marketing-driven bandwagon

    by James Richardson

    Whats the point of being a certified ScrumMaster (TM) if you can't fail the course - once you've paid the cash.

    Of course some people's success using it will vary:
    Just because you use a methodology doesn't mean you're doing anything useful. This applies to any methodology - "agile", "xp", "rup", "waterfall", "tdd"... some teams are rubbish, but thats because they have the wrong people in. (wrong skills, wrong personalities, wrong relationships...)

    Why do you think that so many of outsourcing companies are "CMM Level 5", they have the worst people - so need the most documentation and CYA.

    This works both ways: Great teams will succeed pretty much regardless of the process. They will make it work for them.

    If you want certification for money, go get it, otherwise just pick and choose what you want.

  9. Back to top

    Re: People Over Processes, Change Over Plans

    by Vikas Hazrati


    I am a firm believer in the chinese menu approach. Learn both Scrum and XP and pick what is feasible for your environment, for the current set of people you will work with. As people learn more, they may choose more items. You may never be "pure", but you will continue to improve.


    I agree that the chinese menu would work however I have seen it work with teams who have good mature professionals who know what software development is.


    I have seen teams with hardly any understanding of the right way to develop software mix and match methodologies and end up in a spaghetti of nothing. These teams then end up blaming Agile for all their mishaps.


    For most of the teams I would propose to start with the pure model and once they are comfortable with that then go ahead and customize.
    More here
    So your Agile adoption failed?

  10. Back to top

    Any approach can succeed...

    by Andrew Walker

    But all things being equal XP fills a void in talking about great practices that most methods proudly sidestep. Why avoid the critical part of the process - I don't have the answer to that one - and in my opinion XP is just what the software world needed. Now I tend to use the practices whether the project is run in an XP fashion or not.





    I have used Scrum and XP successfully together, but I have experience with both. If Scrum is introduced without prior knowledge of great engineering practices such as those prescribed by XP, it would be harder for teams that haven't been exposed to it, to get the whole spirit of agility. Having said all that, talented developers can be found successfully delivering business value using almost any kind of method - but I suspect that there are probably XP like practices underpinning their success - they just don't know the label.

Educational Content

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.