Agile Vs XP

[kri shan]

What is the main difference between Agile & XP methodologies ?

[Michael Duffy]

Originally posted by kri shan:
What is the main difference between Agile & XP methodologies ?

I'm not a signatory of the Agile Manifesto, but my take on it is that XP started taking on overtones of religious zealotry. There were other methodologies that claimed agility without the fervor of the XP crowd, and they got together to espouse "agile" without the religious baggage.

[Kishore Dandu]

I would think XP is one of the manifest points of Agile approach. Not a contrarian thing.

I think there is contrasting differences in approaches like XP vs RUP(rational unified process)

[Jeanne Boyarsky]

Kri,
Agile is an umbrella term for many specific methodologies. XP is one of those. Scrum is another.

[Ilja Preuss]

Around a decade ago, there came a number of new processes into being: Scrum, Crystal, FDD, DSDM etc. XP was (and still is) the most controversially discussed of them, but they were often mentioned together. After a short time, that collection of processes became known as "lightweight" processes.

After some time, the proponents of those processes decided to meet for some days to discuss their ideas and to see how much they had in common. To their own suprise, they found that it was a lot, and they were able to agree on a number of values and principles. They also agreed that the term "lightweight" was misleading, that "agile" captured much better what their ideas were about. So they wrote down and signed the "Agile Manifesto", and later founded the Agile Alliance to support all the people who thought alike.

More can be read at http://agilemanifesto.org/history.html

[Don Morgan]

As others mentioned, Agile refers to a number of processes with similar characteristics, where eXtreme Programming (XP) is one specific example of an Agile process.

It is certainly worth learning Agile methods, and also other more traditional processes like RUP or even something like Boehm's spiral model, but I wouldn't get too attached to any of them. You (or your manager) really need to pick and choose specific techniques or practices which will work well for your project, within the constraints of your context, and make it succeed. It is much more important that your project is a success than that you follow some external "process" definition to the letter. Most internal processes I have seen are a hybrid of both the light Agile processes and the more traditional iterative processes like RUP.

[Scott Ambler]

The Agile Unified Process is an example of an agile instantiation of the UP.

- Scott

[Reid M. Pinchback]

Originally posted by Michael Duffy:
but my take on it is that XP started taking on overtones of religious zealotry. There were other methodologies that claimed agility ... and they got together to espouse "agile" without the religious baggage.

I've noticed that seems to be a predictable constant of every successful methodology or technology. Enthusiasm grows because the approach has merit (a good thing) until the enthusiasm grows beyond the real merits (not so good thing). Almost a way of telling if there is any serious use going on for a particular methodology or technology. If you can't find the zealots, then it probably isn't getting much active use.

As a question for those who know more about the XP / Agile history, my impression is that agility has grown to cover a broader range of issues than XP. Is that accurate? In my sporadic stabs at learing about XP my impression was that it was strongly development-team-centric. In other words, that it was a process crafted to deal with a more narrowly-focused problem (things that impact software coding to produce useful software). I haven't gotten as strong an impression of potential organizational myopia from information distributed under the "Agile" label.

[Ilja Preuss]

Originally posted by Don Morgan:
You (or your manager) really need to pick and choose specific techniques or practices which will work well for your project, within the constraints of your context, and make it succeed.

Yes, techniques and practices always need to be selected according to the current needs of the project, *and* the values and principles of the team.

The value of doing a process "by the book" *for some time* - say a month - is in learning how the practices really work together and implement, for example, Agile values and principles. *After* you've done *that*, you are in a much better position to assess what practices are appropriate in a specific situation.

[Ilja Preuss]

Originally posted by Reid M. Pinchback:
Enthusiasm grows because the approach has merit (a good thing) until the enthusiasm grows beyond the real merits (not so good thing).

In my experience, the "religion" starts when the enthusiast meets a "sceptic" who insists that what the enthusiast is doing cannot possibly work.

As a question for those who know more about the XP / Agile history, my impression is that agility has grown to cover a broader range of issues than XP. Is that accurate?

On the one hand, Agile *always* was broader than XP, naturally. Scrum, for example, basically being a project management method, has always been used for non-software projects, as far as I know.

And on the other hand, all the processes have become broader with increasing experience at applying them in different situations. XP, for example, has been shown to work in much larger projects than initially expected by its creators.

[Reid M. Pinchback]

Originally posted by Ilja Preuss:
In my experience, the "religion" starts when the enthusiast meets a "sceptic" who insists that what the enthusiast is doing cannot possibly work.

No doubt that happens at times, but I suspect that wasn't Michael's point and it sure wasn't mine. The reaction to a relatively innocuous comment though is somewhat in line with the point, in that those already following a methodology seem to develop a lower tolerance threshold for doubts or caution of any sort heard from those trying to learn about the methodology before committing to it. Sometimes good practitioners of the methodology can simultaneously be very good at showing how and why it works yet be very effective at driving newcomers away from the methodology before they've had the chance to truly learn and understand it. It isn't that the methodology isn't good, its that the zeal that often surrounds methodologies just results in behaviours that make for a poor sales pitch. I've seen that across easily a half dozen software and project and reengineering methodologies - the buzzwords may change a lot between methodologies, but not so much the way devotees interact with the not-yet-followers.

Maybe "zealotry" isn't the right word, but sometimes a lot of vinegar gets spewed at people instead of honey.
[ February 16, 2006: Message edited by: Reid M. Pinchback ]

[Stan James]

In my experience, the "religion" starts when the enthusiast meets a "sceptic" who insists that what the enthusiast is doing cannot possibly work.

I have trouble when it swings the other way - the enthusiast insists that no other way can possibly work. To hear/read some agile fans (or OO or whatever the latest thing is) criticize the status quo you'd find it hard to believe any useful software was ever built before they came along, that any company ever had a IT advantage that made them wealthy, that anyone ever had any fun meeting customer needs. I'm approaching 28 years on the job and did NOT spend 25 of them in abject misery until XP saved my soul.

[Ilja Preuss]

Originally posted by Stan James:

I'm approaching 28 years on the job and did NOT spend 25 of them in abject misery until XP saved my soul.

Well, then you probably already did *do* XP before it even was "invented"...

[Michael Duffy]

Originally posted by Ilja Preuss:


On the one hand, Agile *always* was broader than XP, naturally. Scrum, for example, basically being a project management method, has always been used for non-software projects, as far as I know.

And on the other hand, all the processes have become broader with increasing experience at applying them in different situations. XP, for example, has been shown to work in much larger projects than initially expected by its creators.

I disagree with this, Ilja. All skeptics aren't wrong. I find that one falls into the zealot trap when the technique becomes the One True Way and no alternatives can even be discussed and criticism is not allowed.

[Michael Duffy]

Originally posted by Stan James:


I have trouble when it swings the other way - the enthusiast insists that no other way can possibly work. To hear/read some agile fans (or OO or whatever the latest thing is) criticize the status quo you'd find it hard to believe any useful software was ever built before they came along, that any company ever had a IT advantage that made them wealthy, that anyone ever had any fun meeting customer needs. I'm approaching 28 years on the job and did NOT spend 25 of them in abject misery until XP saved my soul.

"I'm approaching 28 years on the job and did NOT spend 25 of them in abject misery until XP saved my soul." - I don't think the XP practices are about saving souls or saying that good s'ware wasn't possible before the XP idea took hold.

From what I know of it, XP takes "best practices" and turns them up to eleven. Testing is good; XP has you writing tests first for every class. Code review is an effective way to catch bugs; pair programming is realtime code review at all times. Getting rid of cruft and Saying It Once are good; we'll refactor cruft and repeats away whenever they appear. Consulting with our business customer is good; we'll have them on-site as a member of the team. Frequent integration helps minimize problems; we'll integrate continuously. And so on.

So if you've done fine without XP, it's likely that you've worked on high=functioning teams that were already doing lots of good practices. You're fortunate.

[Ilja Preuss]

Originally posted by Michael Duffy:
I disagree with this, Ilja.

I'm not sure what you are disagreeing with, as what you quoted doesn't seem to connect to what follows...

All skeptics aren't wrong.

They aren't right, either. That is, of course they have all the rights to be skeptic. But whether their fears actually would manifest once they try whatever they are skeptic about - who knows...

So what are we supposed to do?

I find that one falls into the zealot trap when the technique becomes the One True Way and no alternatives can even be discussed and criticism is not allowed.

Does that really happen? In the Agile community? I can't remember such an incident - example please?

[Michael Duffy]

Originally posted by Ilja Preuss:


Does that really happen? In the Agile community? I can't remember such an incident - example please?

Sorry, I think it's a forum quirk. It only seems to quote the last block in a reply. I was disagreeing with this remark that appeared earlier:

"In my experience, the "religion" starts when the enthusiast meets a "sceptic" who insists that what the enthusiast is doing cannot possibly work."

My disagreement has to do with the clash between enthusiast and skeptic. It's not the disagreement that sparks the "religion", it's the inability for the enthusiast to even talk about alternatives or flaws. I'm saying that it's the manner in which the disagreement is handled that tends to spark the "religion" and digging in of heels.

Perhaps not such a strong disagreement.

[Michael Duffy]

quote:All skeptics aren't wrong.



They aren't right, either. That is, of course they have all the rights to be skeptic. But whether their fears actually would manifest once they try whatever they are skeptic about - who knows...

So what are we supposed to do?

I have no answer here, either. It's the questioners that move things forward, right? If Newton's laws became such dogma that questioning wasn't allowed, we'd never have heard about relativity.

But your point is well taken, too. Questioning is sacred, either. Tilt at Newton or Einstein and you might just be a crackpot. Some things are settled. Even if quantum gravity is found and explains some things better, I'll bet that F = ma will still work fine for those dynamic situations with velocities that are small fractions of the speed of light.

Your line of questioning has to have a path forward. It should predict new things or answer old questions or provide a new way of doing something that is demonstrably, measurably better and can be checked independently by others and verified or disproven.

What we're really talking about here is the scientific method. Perhaps not perfect, but still the best way we have for advancing knowledge.

quote:I find that one falls into the zealot trap when the technique becomes the One True Way and no alternatives can even be discussed and criticism is not allowed.

Does that really happen? In the Agile community? I can't remember such an incident - example please?

I was observing an XP discussion years ago, one presided over by Ron Jeffries, where I thought the tone changed from back-and-forth to zealotry. It wasn't any signatory of the Agile manifesto, more the tone of the followers on that board. I watched and participated for a while but dropped out after one long thread too many.

[Ilja Preuss]

Originally posted by Michael Duffy:

My disagreement has to do with the clash between enthusiast and skeptic. It's not the disagreement that sparks the "religion", it's the inability for the enthusiast to even talk about alternatives or flaws. I'm saying that it's the manner in which the disagreement is handled that tends to spark the "religion" and digging in of heels.

Perhaps not such a strong disagreement.

Not a strong one. I just think that it's symmetric - often the skeptic has as much trouble to accept that someone sees alternatives to - or flaws in - what *he* is doing.

[Ilja Preuss]

Originally posted by Michael Duffy:
It's the questioners that move things forward, right?

It's the one who has new ideas (if only on how to combine old ones) *and* is able to communicate them to others in a way that they get interested in it. Or so it seems to me.

If Newton's laws became such dogma that questioning wasn't allowed, we'd never have heard about relativity.

That's too black and white to me. There needs to be a balance between trying new things and working with the known to be good.

Anyway, I'm not sure whom you see as Newton and what as relativity in this context...

Your line of questioning has to have a path forward. It should predict new things or answer old questions or provide a new way of doing something that is demonstrably, measurably better and can be checked independently by others and verified or disproven.

The "measurably" never has worked very well in software "engineering", in my opinion. And still there can - and will - be progress.

What we're really talking about here is the scientific method. Perhaps not perfect, but still the best way we have for advancing knowledge.

The "scientific method" always sounds like something highly objective to me. I don't think that's true, though - there is a lot of politics, partisanship and "gut feel" in science. Scientists are just humans, after all.

But I agree - it's the best way we have...

[Stan James]

If Newton's laws became such dogma that questioning wasn't allowed, we'd never have heard about relativity.

I was reading something about the life-cycle of theories the other day that said Newton knew and acknowledged that his theories were imperfect in some scales, and would not have been surprised in the least that somebody improved on them later. Anybody have any reliable info on Newton and that? He was a proud and ornery cuss, so I'd be a little surprised if he said it in so many words.

There's an old saw to the effect that the other guy's attachment to an idea is in inverse proportion to the facts the has to back it up. Never your own, of course.

Back a few thousand lines at my last post, I wasn't trying to say anything good or bad about XP, but about some of the zealots. We had OO instructors come in and start a course by saying "Everything you ever learned about software design is wrong." That was an idiotic thing to say, and a lot of fine procedural folk tuned out and didn't get anything good this guy accidentally said later.

And in truth the process I ran before I learned about Agile was rather BRUF, mainly based on writing the user manual first for large jobs. In my defense, I did arrive independently at a strong iterative style totally on board with Frequent Delivery of Running Tested Features.