What process are you using?

What process is everyone using? At my work we are using a combination of UP and XP. I find merits in both that its hard to choose one or the other. I'd like to know what others are finding.
I'm curious in Agile Development. Don't know much about it though. Is it something similar to UP?
Thanks for your opinion in advance.
/rick

I've not yet worked on a project that uses a defined process: I'm three years or so into my professional career and have not worked for a company that has adopted the discipline of using process(es) for its work. However, in my reading, the experts in the field, some of whom I consider to be Kent Beck (XP), Craig Larman (RUP), Alistair Cockburn (there are many other brilliant "process" minds out there), recommend that each project find its own process that suits it. This process may be one of the aforementioned ones, or it may be a combination of techniques from many. Hence, the issue is not choosing a single process but choosing one (or bits from many) that work(s) for the project, based on team size, deadline, deliverables, customer, technology, etc.
I'll have to defer to someone with a firmer grasp of both agile software processes in general and UP for your other question.
[ February 18, 2002: Message edited by: Craig Demyanovich ]
[ February 18, 2002: Message edited by: Craig Demyanovich ]

Originally posted by rick salsa:
What process is everyone using? At my work we are using a combination of UP and XP. I find merits in both that its hard to choose one or the other. I'd like to know what others are finding.
I'm curious in Agile Development. Don't know much about it though. Is it something similar to UP?
Thanks for your opinion in advance.
/rick

Rick,
I just got back from our monthly Java Users Group meeting and Andy Hunt spoke about Agile methods.
Here is a web site that will help you
get an overview of Agile Development
http://www.agilealliance.org/
Sometimes you don't have much of a choice and
have to do what the sponsor decides
is best for the project (for better or
for worse). I personally prefer the S.O.P. methodology .. Seat of Pants :-) or the brute
force and awkwardness approach of a linebacker
on the football field :-) XP and Agile sound
very much like those two.
They are starting a discussion group
in the research triangle park area (North Carolina) to discuss XP and Agile. I will post
the listserver address as soon as it becomes available.
Conrad

I developed the process at my last company. Frankly, I doubt most companies follow a published process. Most use home grown. To a first order, all are the same.
--Mark

Originally posted by rick salsa:
What process is everyone using? At my work we are using a combination of UP and XP. I find merits in both that its hard to choose one or the other. I'd like to know what others are finding.
I'm curious in Agile Development. Don't know much about it though. Is it something similar to UP?

XP is one member of Agile methodology family(maybe the most important member). If you are familiar with XP, you know a lot of sense of Agile Development.
The best introduction to Agile methodology is Martin Fowler's The New Methodology article.
Also follow Conrad's link to read The Agile Manifesto, and here is the interpretation and comments to the Manifesto by Martin Fowler and Jim Highsmith.
[ February 18, 2002: Message edited by: Doug Wang ]

In my company, we used a process somewhat
similar to ICONIX. It is briefly discussed
in a series of articles at sdmagazine.com
The article
We do not have clear boundaries b/w the phases (elaboration, construction etc..). We just know we're there intuitively. Our iterations are defined by the set of usecases+CRC cards. We use CRC cards extensively. In terms of UML artifacts, we only use: (a) usecases (b) sequence diagrams. (c) class diagrams. We do use activity diagrams sometimes to get a feel of the workflow of the app. The customer is involved from day one although not on site - we actually have to travel to their place instead.

what mark has mentioned is most of the times right . the companies use home - grown process. but , those are all mature organisations. it becomes really cost - effective or rather advantageous to use exiting process for start-ups.
that is the reason SEI - CMM has got various levels from intial process( Level - 1 ) to optimizing process ( Level - 5 )
plus , the complexity of projects is so high , it is very difficult to use a single process. one of the reasons of using iterative development with such kinds of processes is to avoid the risk & become more informed for future development.
it rests squarely on the shoulders of organisation which process to use , whether home - grown or exiting methodologies like up , rup , xp , crystal .

I personally prefer the S.O.P. methodology .. Seat of Pants :-) or the brute
force and awkwardness approach of a linebacker
on the football field :-) XP and Agile sound
very much like those two.

I don't understand - could you please elaborate?
Regards, Ilja

I would opinion - most companies do not have a published methodology and do not follow any specific methodology. Every compnay or rather a group in the company adopts a methodology by retrofitting any of the popular methodologies. Most methodologies are flexible/adapatible- and I think one should adpat them based on needs of compnay/project.
$.02
Sanjay

New process ideas need a champion to "sell it" to his peers and to management. This can be very political.
Start-ups are more interested in fast results and tend to reward seat-of-the-pants development. Most would not admit this. Many "talk" XP, but I know of no company which really does XP. To my mind, XP requires that the customer be daily involved with SW development and testing. Some startups don't even have a customer yet, let alone one willing to invest a person to be on with the team.
In my opinion the type of process is less important than how well developers work together.

I agree with Klay's views. Nothng like a team working together. Nothing like a good project lead or an architect- if you don't have this no methodology would be of any help.
Sanjay

Thanks everyone!!
I guess we have our own homegrown process as well. We use some of the UML artifacts to help grasp the tasks at hand and model our projects. Although we aren't practicing Pair Programming yet (We all know project managers really don't like this one

), we are really seeing the benefit of unit testing and refactoring. I find that even though some companies follow RUP, they are too scare to make changes to the architecture or code base. Old habits die hard I guess. I found at our company, now that the bosses have adopted some of XP's methodologies, this attitude has changed. Weird....

I find both have excellent features that make it hard to choose one over the other.
Has anyone looked into Aspect-Oriented Programming yet? Sounds interesting...
/rick
[ February 19, 2002: Message edited by: rick salsa ]

Originally posted by Klay:
To my mind, XP requires that the customer be daily involved with SW development and testing. Some startups don't even have a customer yet, let alone one willing to invest a person to be on with the team.

Please notice that "Customer" is a *role* in XP. See http://c2.com/cgi/wiki?TheMythicalXpCustomer

Originally posted by shailesh sonavadekar:
what mark has mentioned is most of the times right . the companies use home - grown process. but , those are all mature organisations. it becomes really cost - effective or rather advantageous to use exiting process for start-ups.
that is the reason SEI - CMM has got various levels from intial process( Level - 1 ) to optimizing process ( Level - 5 )

Actually, I was under the impression most start-ups use home grown processes; although usually those processes are, to follow the analogy, harvested way to early. Many startups are seat of their pants, and the successful ones are the ones who don't screw up the same way twice.
My feeling is most processes are too heavyweight for startups (including XP to some extend--of course, I think XP has problems of its own which would effect startups). But this I mean, while all processes say, "hey you need to adapt this to suit your needs," often a small startup (<10 engineers), will throw out more then they'd take, so it'd probably be easier to build from bottom up, rather then throw out from top down.
--Mark

Originally posted by Mark Herschberg:
My feeling is most processes are too heavyweight for startups (including XP to some extend--of course, I think XP has problems of its own which would effect startups).

Actually, XPers suggest to start small (at least allow that) and grow over time. This gives the project flexibility and less risk.

Originally by Kent Beck:
In fact, at the beginning of a project, you can't spend much money at all. The investment has to start small and grow over time. After a while, you can productively spend more and more money.

mark , if the start-up is offshoot from people working in big , mature software companies , then there will not be intial chaos.
but , if it is from just out of college engineers , then I really find difficult to digest the fact that they have home grown process which will work all the time. so , sei puts all such organisations at level - I , where chaos is bound to be there.

rick , aspect oriented programming addresses the issue which oo programming can not address. thus , the thorough knowledge of oo technology would be required to move on to this new technology , which grady booch says as the disruptive technology on horizon.

Originally posted by Doug Wang:
Actually, XPers suggest to start small (at least allow that) and grow over time. This gives the project flexibility and less risk.

Yeah, I was expecting something like this. I disagree. Setting up an automated test harness is a significant amount of work for a startup. Setting up a seemless integration process isn't trivial. Teaching everyone to work in XP mode is no small task. The cost of all this is higher then most people realize.
As for less, risk, I strongly disagree with that, but that's another whole topic.
--Mark

Originally posted by shailesh sonavadekar:
mark , if the start-up is offshoot from people working in big , mature software companies , then there will not be intial chaos.
but , if it is from just out of college engineers , then I really find difficult to digest the fact that they have home grown process which will work all the time. so , sei puts all such organisations at level - I , where chaos is bound to be there.

OK, we agree, we're just defining things slightly differently. Chaos, which usually isn't pure chaos, but rather a poorly planned system, is still a process, that's what I meant.
No company just says, "it'll happen." Rather, the say "um, you code this, I'll code that, he'll take care of the rest" and think it's all set. But without headlights, they fail to see the brick wall 2 months in front of them.

--Mark

Originally posted by Mark Herschberg:

But without headlights, they fail to see the brick wall 2 months in front of them.

--Mark

In my experience, they most often see the wall, but hope that "it won't hit them". In their view they are just so busy driving that they don't find the time to steer... :roll:
[ February 20, 2002: Message edited by: Ilja Preuss ]