Wednesday, April 30, 2008

XP and Scrum

There is an interesting thread going on right now on the yahoo XP group - XP and Scrum. Before introduced to a real agile project, I had read up on Scrum and it made a lot of sense at the time, but I certainly did not understand it. I suspect it's possible to figure out what agility actually means by reading about it - but for many, including me, I had to experience it before I 'got it'.

Both approaches use what I like to think of as common sense - but common sense is actually a misnomer, its not that common. They share many ideals, but the real difference is in the XP technical practices. For me, this is absolutely key. I believe that many of the failings of the numerous practices and methodologies out there are due to the lack of column space dedicated to great techniques to apply to programming. Usually methods specify what documents and pictures should be created and who needs to sign them off - but on many occasions these artifacts can be viewed as waste. As Kent Beck puts it, testing, programming, listening and designing - thats all there is to it - anything else and someone is trying to sell you something.

So, by no means do I view Scrum as a bad thing, but I do think that you stand a better chance of success by following the XP alone rather than Scrum alone - which is purposely vague when it comes down to programming.

Of course, the point is moot, because you don't have to adopt a single approach, you can have both.


Brad Wiederholt said...

So, any advice on when it is safe to start "rolling your own" process, taking a bit of this and a bit of that to make something work for you or the organization?

I wonder because I see a lot of folks adopt agile processes that "we've tailored for ourselves" right out of the gate. I don't think they've even tried following just one of the methodologies to the tee for a single project.

Seems to me that one would need a project or two under their belt with the "proven" method before they start to think that they can adapt to an organization.


Andrew said...

Brad, this is an interesting question and I like your line of reasoning. If you fully understand how the various aspects of the methods work and their relationships with one another, you probably can.

I would be very cautious with this approach though - take the example of XP and refactoring. If you try to refactor without unit tests, its like walking the tightrope without a safety net. Trying to adopt any form of agility without at least one customer representative present is likely doomed and could not really be termed agile - IMHO.

As Paul likes to put it - you should learn to walk before you try to run - and I like this analogy.