One of the things I talked about during my Pre-con sessions ate TechEd Barcelona was how to Implement Scrum using Team System and the Scrum For Team System Project Template.
I like XP, but I really like Scrum as a methodology for several reasons:
- It's pretty open to customization
It talks about the iterations planning, release planning and solely lies in the real of management practices. It says nothing about Engineering practices (besides Estimation) - leaving much leg room to do whatever you want during an iteration. You can also change your mind about the way you work between iterations if something does not suit you.
- It does not contain the word "Extreme" in its name
This is a really important thing. You see, eXtreme Programming, when compared to Scrum, is really a superset of the Scrum methodology in many ways - it contains all of the management ideas of Scrum (short iterations, estimation, communication, simplicity and feedback, but is also adds the layer of engineering practices that is missing from Scrum (Unit testing and TDD, Pair programming, Continuous Integration etc..). But it's naming is a real problem.
It's a lot easier showing Scrum as a methodology to management than XP, because it "sounds" very extreme, although many of the concepts are the same. With scrum I can always say "lets start with short iterations and daily meetings (Scrums) and see what happens next. I can then add XP practices into the Scrum mix incrementally. Because Scrum does not talk about them, people will be less scared of trying things out, and it won't feel as extreme anymore. With XP I need to explain the initial effort to begin with, and always worry that people will be too scared of a change that might be too big for them.
Sure, you can try to implement XP slowly , practice by practice, but the overall feeling is that your overall changes will be much bigger.
With Scrum it's a syntactical, very subtle notion of change. So it's easy to digest for people who may fear change.
Every successful Agile project I've seen has used a combination of practices from several methodologies (you can always attribute some to XP and Some to Scrum, or just XP) - they always create their own version of e methodology 9 it's nether Scrum or XP, ("ScrumP" ? "Xrum" ?) - it's a mutant methodology that fits what that organization or team can do right now. Forcing it any other way will usually lead to failure in adoption - people don't like to be forced to do things they don't think will work - they need to choose to do it. They do whatever they think they need to do anyway - they may just tell management they do things like they are told.
When I interview companies, the managers always think that they people under them work in a specific way. Interviewing the actual people who do the work usually shows a very different picture - that of people making stuff work despite the rules given, not because of them. It's really enlightening. In a "Jurassic park" sort of theme you could say that "Life always finds a way" - people figure out what will make them do what they need to get done, regardless of the obstacles in their path. Send emails instead of filling forms, having a watercooler chat instead of sending an email, walking across the building instead of making a phone call - using a whiteboard instead of Rational Rose - those sorts of things. Life finds a way to exist in the harsh world of constraints we live in - it will be foolish to kid ourselves into thinking that just telling people to work a certain way will actually make them do it correctly.
They need to want to do it that certain way first. And that's all there is to it really. Gather a group of highly motivated people in a room - lock them up and give them whatever they need to get a task done and remove obstacles, and wait until they have finished. That's the basic premise behind all productive teams.
It's the "how do I give them what they need" that changes between methodologies, really. How do you give them better communication with the client and understand requirements? How do you make sure they stay focused (closed iterations where nothing can change), how do yo help them deal with change (teach them about unit testing, TDD and Continuous Integration) etc etc..
Anyway.
I'm writing this post because I remembered that I used a comic from ImplementingScrum.Com in my session at TechEd (with permission). Here's the Comic I used (my favorite):
There are more cartoons there for your reading pleasure.