Difference between agile and XP?

[Volker Schnitzer]

I am trying to keep up with these recent developments in the way programming and database design are done. I am a little bit confused if there is a difference between agile and XP. It appears that sometimes these terms are being used interchangeably. And is UML related to this as well?
Volker

[Lasse Koskela]

I am a little bit confused if there is a difference between agile and XP. It appears that sometimes these terms are being used interchangeably.

There is a difference. "Agile" is an property/adjective, describing how quickly something (a process in our case) can switch direction (adapt to new information). "Agile software development" (or agile methods, methodologies, etc.) is a category of software development methodologies with that (agile) property. XP is just one process that happens to belong under that category. There are others as well, but they don't get nearly as much mind-share as XP.

And is UML related to this as well?

Sure, but not any more than it is related to BDUF, waterfall, etc. processes. It's a tool for communication, documentation, and lately even code generation, and can be applied within a number of different types of processes.

[Scott Ambler]

If you're interested in how UML fits into the agile picture, drop by www.agilemodeling.com. One essay that might interest you is www.agilemodeling.com/essays/realisticUML.htm where I discuss the issue that the UML isn't anywhere near sufficient for real world development -- for example, it says nothing about data modeling or UI modeling, and when was the last time you built a business app without a database on the back end or a user interface on the front end?
If you want to come up to speed on UML 2, you'll find http://www.agilemodeling.com/essays/umlDiagrams.htm -- think of it as an online version of UML distilled, but free.
- Scott

[Ilja Preuss]

In the late 90's there existed several software development processes which were called "leightweight" - XP, Scrum, Crystal, FDD, DSDM to name just a few.
In early 2001, some of the proponents of those processes were curious on how much they had in common, besides not liking the "old way" of doing software development.
They were all surprised to find two things: There were a bunch of common values and principles they all could subscribe to. And they dislike the term "leightweight" and found that "agile" better matched their thinking of what they wanted to accomplish.
So they wrote down those values and principles and called it the "Agile Manifesto"; a little bit later the Agile Alliance was founded to be able to more effectively communicate about those values and principles and how they apply to software development.
Since then, this form of software development is known as "Agile Software Development".
For more detailed info see http://www.agilemanifesto.org/history.html

[Stan James]

It's Friday ... must be time for me to plug Alistair Cockburn's Agile Software Development again. He does a nice survey of agile methods. In other books he talks about his own Crystal methods and how to align a given project with an appropriate method.
Hey, I just looked and http://www.agilealliance.com/home has a lot more content than last time I looked. Another good jumping off point for many agile ideas.

[Garry Garrson]

Hi All,

Thanks for such an informative board.

I would appreciate it if my questions could be answered.

1.)if RUP is a process how does the differ from UML?
2.)I understand UML to be format use �use cases� but what else is it be used for today in the real world?
3.)if XP is a process like waterfall (in my limited experience) but �lighter� what ever that means (if I understand correctly it�s less burocratic) why does XP not seem to be main stream? Particularly in web based development where development cycles are fairly short 3~6 months max
4.)When would u use RUP instead of UML
5.)Does any main stream development shops (web based development) still use waterfall method? If not where is the trend moving?
6.)Who typically create the UML? Project manager?
7.) What currents process in active use (web based) besides XP for short term 3~6 months 6~10 developer Java teams?

I apologies in advance if any of my questions look silly.

Thanks for your time.

Gary

[Don Stadler]

Originally posted by Garry Garrson:
Hi All,

Thanks for such an informative board.

I would appreciate it if my questions could be answered.

1.)if RUP is a process how does the differ from UML?
2.)I understand UML to be format use �use cases� but what else is it be used for today in the real world?
3.)if XP is a process like waterfall (in my limited experience) but �lighter� what ever that means (if I understand correctly it�s less burocratic) why does XP not seem to be main stream? Particularly in web based development where development cycles are fairly short 3~6 months max
4.)When would u use RUP instead of UML
5.)Does any main stream development shops (web based development) still use waterfall method? If not where is the trend moving?
6.)Who typically create the UML? Project manager?
7.) What currents process in active use (web based) besides XP for short term 3~6 months 6~10 developer Java teams?

I apologies in advance if any of my questions look silly.

Thanks for your time.

Gary

Nothing silly about it, Gary!

1) UML isn't a process - it is a modelling language. RUP (Rational Unified Process) is roughly the same thing as UP (Unified Process, de-Rationalized). Minus the Rational corporation that is. RUP/UP can be 'lightweight' and iterative. In practice it usually is not.

2) xP is process but not really anything like waterfall. xP is iterative. In waterfall you get all your design work finished before you begin coding. With xP (particularly with TDD - Test-Driven Design) you begin with a very swift inception (goal definition) and cut out the design. If you're using TDD the first thing you do is write the test cases to define the deliverable you are aiming at. When the test cases 'go green' it's time for the next iteration - or to deliver.

3) Because of inertia, and for very large and formal IT projects xP may not scale well. It's better suitedf for small projects or for small teams working within large projects with well-defined interfaces.

4) You wouldn't. RUP is the process, UML is the language. You use them together. xP project may also use UML if the customer demands formal design artifacts, although it's against the spirit of xP. I've seen them use UML after the coding was done to document the design.

5) Many. They may call it something else (typically iterative) but if it walks like waterfall and quacks like waterfall, it's waterfall. It's not unknown for the architects to be doing waterfall while the developers rush ahead and do iterative. Which makes the architects completely rendundant.

6) Usually analysts and designers use UML, though many developers also do analysis. I've done it myself that way.

7) See other comments on this board. RUP/UP and xP are far from the only processes.

[Warren Dew]

Garry Garrson:

if XP is a process like waterfall (in my limited experience) but �lighter� what ever that means (if I understand correctly it�s less burocratic) why does XP not seem to be main stream? Particularly in web based development where development cycles are fairly short 3~6 months max

I'd suggest there are several reasons:

1. XP hasn't been around that long; it hasn't had time to diffuse through the industry yet.

2. XP and other agile processes don't always handle product management well, because of the close link between the developers and the customer. I've seen this result in excessive repolishing of the work in early iterations, at the cost of never getting the rest of the features done.

3. XP includes some practices that don't mesh well with some programming styles, so it's difficult to use in some teams.

Don Stadler:

It's not unknown for the architects to be doing waterfall while the developers rush ahead and do iterative. Which makes the architects completely rendundant.

Either that, or it makes the developers redundant until the architects are done....

[Don Stadler]

Well, in the case I was thinking about, Warren, they probably both were in the end. The deadline was swiftly approaching and the architects were in a jello-fight, so the developers started designing and building. The Rose model was an incredible mess (I know because I had to clean it up!

[Ilja Preuss]

Originally posted by Warren Dew:
XP and other agile processes don't always handle product management well, because of the close link between the developers and the customer. I've seen this result in excessive repolishing of the work in early iterations, at the cost of never getting the rest of the features done.

Am I understanding you correctly that in your experience/opinion, removing the close communication between Customer and developers would help the developers to produce something closer to the Customer's needs, and therefore reduce the need for "excessive repolishing"?

[Ilja Preuss]

Originally posted by Don Stadler:
xP project may also use UML if the customer demands formal design artifacts, although it's against the spirit of xP. I've seen them use UML after the coding was done to document the design.

Actually most XP developers I know use UML without the Customer requesting it - just differently than in other projects. They don't fill cabinets with paper and are rather unlikely to draw class diagrams in expensive modeling tools to somehow generate code from it.

Instead they gather around whiteboards to sketch some diagrams during discussions, keep them on the wall while they make sense and erase them when they become unnecessary or out of date.

[Warren Dew]

Ilja Preuss:

Am I understanding you correctly that in your experience/opinion, removing the close communication between Customer and developers would help the developers to produce something closer to the Customer's needs, and therefore reduce the need for "excessive repolishing"?

In my experience, having a dedicated product manager managing the product, rather than having product management emerge from interaction between the customer and developers, can result in better prioritization. This can help with getting the overall product done in time by avoiding spending excessive amounts of time on relatively minor things that just happen to have captured the customer's focus. An experienced product manager will have a better understanding of and be more cognizant of schedular impacts than the typical customer, and will be able to better discern customers' actual needs from their statements than the typical programmer.

[Ilja Preuss]

I see.

I'm not sure that putting a Product Manager *between* the Customer and the developers is optimal, though. It's too likely to get a "Chinese whisper" effect. Also direct contact to the customer can be quite motivating for the developers (geeks really like the warm feeling that what they produce actually means something to someone )

I think I'd prefer to see the Product Manager as a *service to the Customer* to help him come up with his requirements and a good prioarization, and to communicate it to the developers.

[Garry Garrson]

Thanks for answering my questions, it�s been very helpful!


"1) UML isn't a process - it is a modelling language. RUP (Rational Unified Process) is roughly the same thing as UP (Unified Process, de-Rationalized). Minus the Rational corporation that is. RUP/UP can be 'lightweight' and iterative. In practice it usually is not."

Question: From what I have read RUP does seem quite detailed for small projects, Correct?

I am a little confused are you saying that there is another process call �UP� (Unified Process, de-Rationalized) that is preferred in some cases? If so where could I read up on that? What are your thoughts on it?

Thanks,

Gary

[Lasse Koskela]

Originally posted by Garry Garrson:
From what I have read RUP does seem quite detailed for small projects, Correct?

Well, if you tailor RUP enough, you can end up with something that looks very close to XP-by-the-book. However, the typical RUP instances I've seen are most definitely not suitable for a small team. Heck, they haven't been too suitable for any team.

If you're interested in applying RUP for a small team, you might want to read Software Development for Small Teams: A RUP-Centric Approach.

Originally posted by Garry Garrson:
I am a little confused are you saying that there is another process call "UP" (Unified Process, de-Rationalized) that is preferred in some cases? If so where could I read up on that? What are your thoughts on it?

There's a book on the Unified Process called The Unified Software Development Process by Ivar Jacobson, Grady Booch and Jim Rumbaugh. The way I see it, the UP and the RUP aren't that much different. The fundamental ideas are the same, RUP is just a bit more polished and productized.

[Ilja Preuss]

Originally posted by Garry Garrson:
Question: From what I have read RUP does seem quite detailed for small projects, Correct?

RUP is not a ready to use process, but a process framework. That is, it basically says "you could do this, possibly that, those techniques might be a good idea too, etc. pp. - and do it iteratively, please." You are then expected to find out for yourself what to do and what to ignore.

Most teams tend to do way too much of the practices of RUP, though - probably simply because they are there, seem like a good idea and the people feel more save by doing more of the adviced things. What they end up with is a lot of wasted time, unfortunately. Starting with a *minimal* set of practices (like described by XP) and adding new ones when needs become apparent often is the better idea.

[Garry Garrson]

What is LDAP & Active Directory?


I am going to take a stab at my questions so as to help direct your answers if that makes any sense.


1.) What is Active Directory (is active directory the repository for user name, PWD other confidential information like access rights and what groups this user belongs to ? )

2.) What is LDAP (is L D A P - a standard if so, for what?)

3.) How do they relate to each other ?


If someone could help me understand these concepts (for the purpose of a single user sign on to more than one application from differnt vendors better I would much appreciate it.

From what I understand (although no experience so probably wrong) if an application (say one you built) needs to integrate to a third party application where both your application and the 3rd party require authentication each product must support LDAP . Where does Active Directory come into it? I guess there are different LDAP & Active Directory vendors?



Question: This probably sounds ridiculous but why could you not just use encrypted XML to get authenticated on the 3rd party application (to send user name & password)?

[Don Stadler]

Originally posted by Ilja Preuss:


Am I understanding you correctly that in your experience/opinion, removing the close communication between Customer and developers would help the developers to produce something closer to the Customer's needs, and therefore reduce the need for "excessive repolishing"?

Hmm, Ilja,. I wonder whether we're not working with unclear definitions of who is the 'Customer' here? xP works fine if the definitions and the goals are straight.

In the case that Warren Drew outlined I could argue that the 'Product Manager' might be the proper Customer. Because it's the kind of deal where the goal is to cust costs by creating a product which can be resold elsewhere rather than to create an application perfectly customized to a single organization. A different animal. And in the latter case I think I agree with Warren. You absolutely need someone with a vision of what that product's aims and goals are. And that person is the customer.

In the early days that can be the project inceptor or lead - in fact probably will be. In this sense Craig McClanahan was the customer in the early days of Struts, for an example.

Or am I full of crap? You tell me!

[Don Stadler]

Originally posted by Garry Garrson:
What is LDAP & Active Directory?


I am going to take a stab at my questions so as to help direct your answers if that makes any sense.


1.) What is Active Directory (is active directory the repository for user name, PWD other confidential information like access rights and what groups this user belongs to ? )

2.) What is LDAP (is L D A P - a standard if so, for what?)

3.) How do they relate to each other ?


If someone could help me understand these concepts (for the purpose of a single user sign on to more than one application from differnt vendors better I would much appreciate it.

From what I understand (although no experience so probably wrong) if an application (say one you built) needs to integrate to a third party application where both your application and the 3rd party require authentication each product must support LDAP . Where does Active Directory come into it? I guess there are different LDAP & Active Directory vendors?



Question: This probably sounds ridiculous but why could you not just use encrypted XML to get authenticated on the 3rd party application (to send user name & password)?

The short answer to your question is that Active Directory and LDAP are both directory services. You can think of a directory service as akin to a database optimized for read operations. Directory service reads are dirt-cheap but writes are expensive relative to a DB. LDAP is the Unix flavor, Active Directory is M$. I think.

The long answer is that neither AD or LDAP belong in this forum as they aren't process. I suggest you try the EJB forum and ask about JNDI, which uses LDAP or possibly the Other Java API's forum. In the absence of a Javaranch forum dealing with generalized data access questions this is the best I can do!
[ November 30, 2004: Message edited by: Don Stadler ]

[Ilja Preuss]

Originally posted by Don Stadler:
Or am I full of crap? You tell me!

Well, you aren't!

Still, even if the Product Manager was the Customer, I wouldn't want to put him *between* the developers and the actual customers/users of the system (at least a couple of them). He might have the final say, but I don't see why he'd need to "protect" the developers from knowing how the software actually will get used first hand.

[Don Stadler]

Originally posted by Ilja Preuss:


Well, you aren't!

Still, even if the Product Manager was the Customer, I wouldn't want to put him *between* the developers and the actual customers/users of the system (at least a couple of them). He might have the final say, but I don't see why he'd need to "protect" the developers from knowing how the software actually will get used first hand.

Hmm. Good point. The problem is there is a divergence of interest between the users and the interests of the project. The deal is that the users accept something less than a custom solution for less than the cost of a custom solution. So they are going to be pushing for their own interest (a customized solution) and hang the objective of a saleable product.

An answer would be for the product manager to be part of the team - and always on the customer interaction. So he or she is in the position to say 'wait a minute' and push back when the customer pushes too far.

In it's current theoritical state xP works better for true custom software than for products, because in theory these kind of conflicts can't happen under xP. Actually they can (even in pure custom development) because there is rarely a single customer in the user community. It's often a comittee and usually you have to satisfy a constituency (stake-holders and the like). Rather than an individual or a cohesive team of users.

[dinaker prasad]

From my experience

Having a product manager is a good thing.

Product managers typically understand the domain requirements/problems/issues better because of his or her experince in sales/marketing or what ever back ground they come from.

they also tweak the requirements to come up with a product which is a win-win both for users and clients(company comming up with the product).

Having a product manager helps to hire BA's and developers that don't have the domain knowledge but have the technical expertise.

as far as process goes, i dont think having Product manager role makes any difference to how a process is adopted.

thanks
dinaker