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.
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.
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.
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 😀
I seem to find the phrase “Lean Programming” calms people down.