• Skip to main content
  • Skip to footer

Agile Pain Relief Consulting

Scrum and Agile Training and Resources

  • Certified Scrum Training
    • Certified ScrumMaster (CSM) Training
    • Advanced Scrum Master Certification (A-CSM)
    • Certified Scrum Product Owner (CSPO) Training
    • Private Scrum & Agile Training
      • Agile Foundations Private Training
    • Choose the Right Scrum Training for Your Needs
    • FAQs and Policies
  • What Is Scrum
  • Resources
    • A Jargon-Free Introduction to Scrum
    • *NEW* Agile Glossary and Reference Library
    • The Guide to Effective Agile Retrospectives
    • Online Agile Teams Game (Beta)
    • Five Steps for Creating High-Performance Teams FREE ebook
    • Foundational Scrum Free Learning Series
    • The Story of a Sprint
    • Free Virtual Scrum Meet-Up
    • Get Scrum Education Units (SEU)
    • Articles & Interviews
    • Newsletter
  • Blog
    • Scrum by Example – Stories for the Working ScrumMaster
    • Beyond Scrum Blog Series
    • Scrum Anti-Patterns – How We Hold Back Our Scrum Teams

Why I speak of Agile/Scrum and not XP – or Language matters

November 20, 2008 by Mark Levison 4 Comments

In Call it what it is!! Dave Rooney says if you’re doing Scrum with XP engineering practices, then call it XP? Well, Dave, there’s a story that explains why I generally don’t lead with the language of XP:

A few years ago when I was first learning about Agile and doing my reading several of co-workers (all developers) saw what I was reading: eXtreme Programming, Test Driven Development and Pair Programming. Their reaction: that’s crazy stuff, you’re not going to try introducing that around here. Management was a little more open but also saw it as odd. Finally I read the XP mailing list and felt like I was in a room of fanatics (circa 2002/2003). At that stage I got turned off. In the end I introduced unit testing and code reviews- it was the best I could do.

I started reading about Crystal (hello Alistair), but there was no community behind it (the mailing list had 4-5 people) and then I stumbled across Scrum. Perfect no – nothing is. But it gave us a language to use that didn’t scare management or the developers. Now several years and two acquisitions later I’m helping to introduce TDD to a development organisation in excess of a thousand people.

If I had tried to sell XP I probably wouldn’t be in this position today. So like it or not language matters and you have to go with what resonates with people. Today if I were talking to Senior Management at an organisation I would talk about quality and waste removal. To the mid level managers I would talk about Agile (generic) and to team members both Agile and Engineering Practices.

Finally it helps to remember that the engineering practices predate Scrum and XP – if my memory serves they come from Kent Beck and the smalltalk world. So maybe we should say: Scrum and Smalltalk Engineering practices.

N.B. Not everyone who was on the XP mailing list will have had the same experience. In addition, at the time Ron J. was part of the problem for me (sorry Ron). I found his tone very rough – since I’ve come to appreciate how he can ask why in just the right place.

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.

Filed Under: Software Development

About Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.

Reader Interactions

Comments

  1. Adam Sroka says

    November 20, 2008 at 6:21 pm

    AFAIK, the term “engineering practices” is a relatively new one and came out of the Scrum community. I first recalling hearing it used by Tobias Mayer.

    All of the practices that make up XP come from somewhere else. XP itself was an evolution of the practices Kent Beck was using at the time he was working the Chrysler Comprehensive Compensation project. The term Extreme Programming referred to the idea of taking a certain set of practices which worked really well, and doing them all, together, all the time, to the exclusion of anything else. Thus taking the things that work and pushing them to the extreme.

    XP may sound a bit… well, extreme. However, I find that when people understand the meaning of the term they are less likely to object to it.

    I was on the XP list back in 2002/2003. As for zealotry I plead the Fifth.

    Reply
  2. Alan says

    November 20, 2008 at 8:03 pm

    I agree. Language matters. There will always be these “what’s in a name?” people who don’t mind, and don’t see why anyone else would mind. But they’re wrong. Every marketer knows the choice of name is important. There was a recent blog posting about this:

    https://blog.magenic.com/blogs/aarone/archive/2008/11/19/Pair-Programming-_2D00_-Marketing-FAIL.aspx

    He recommends rebranding XP “Collaborative Programming”. I like this suggestion. I’m not sure that covers all the bases, but it’s a start. The problem is that are a lot of books and web pages are that use “XP” and “extreme” and other words that don’t sell well, and people will be suspicious of a sudden rebranding. But I think it has to be done, slowly but surely.

    Reply
  3. Adam Sroka says

    November 20, 2008 at 8:45 pm

    Another thought:

    What I need is a way to say, “this minimal set of practices that work very well together. Not necessarily to the exclusion of anything else, but at least these.” To those familiar with XP it implies a certain set of inclusive practices. If you remove any of them it is no longer XP.

    What I don’t like about the “Scrum with Engineering Practices” idea, as I have commented on my own blog, is the idea that the practices are individually and collectively optional. This leads to the idea that I can have absolutely no technical discipline at all and still call what I am doing scrum (After all, we have daily meetings.) Or, that I can introduce certain practices that I like and leave out the others. The problem being that unless I have used these practices together there is a good chance that I don’t really know what I can/should get out of them.

    So, I want a way to say, “We do all these things, all the time. We *do not* merely do some of these things, some of the time.” How do I say that? In two letters or less 😀

    Reply
  4. Carlton Nettleton says

    November 21, 2008 at 4:21 pm

    I seem to find the phrase “Lean Programming” calms people down.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Footer

  • Certified Scrum Training
  • Private Training
  • Effective Agile Retrospectives
  • Agile Reference Library
  • About Us
  • FAQs and Policies
  • Site Map
  • Partners

Contact Us

  • 877-248-8277

Follow Us

  • LinkedIn
  • Mastodon
  • RSS


Subscribe for Scrum & Agile news and more resources





© 2011–2023 Mark Levison & Agile Pain Relief