Caution - Vague questions inside.

[Dirk Schreckmann]

In basic terms...
I'm involved with a group of Java programmers that have decided to start tackling some simple projects so as to gain experience in project managment and to have another item to list on the ol' resume. Members of the group have a range of programming experience (from "just beginning" to "been programming in some language longer than you've been alive") but nobody would claim to have any experience in project management.
I'm pushing the group to first discuss the dominant project management/development methodologies/philosophies so that we may begin to better understand what is involved in successfully completing a project and to begin to develop a unifying philosophy under which we'll coordinate our efforts at approaching whatever problem we adopt to solve.
For next week, I've volunteered to give a brief presentation summarizing the dominant practices in use in project management/development circles. I've thought to cover ideas from the Agile Development, the Unified Process, and the eXtreme Programming worlds.
I'd appreciate any advice concerning information that belongs in a presentation as I've described. Over the next couple of days I'll be trying to answer questions such as: In 500 words or less, what is agile development all about? What is the UP? What is XP? What's involved in successful project management? I'll likely ask a few more-specific questions over the next week.

[Dirk Schreckmann]

Another question I think I should answer:
What is Big Design Upfront development?

[Ilja Preuss]

Hi Dirk!
I just run across a paper that might be interesting to you: Agile software development methods - Review and analysis. I didn't take a deeper look yet, but it looks promising - it also covers RUP, as far as I remember.
Another tip: For your projects try to get an "as real" customer as possible - that is, someone who tries to get as much value from the limited resources of the team as possible, while working with conflicting and reacting to changing forces.
Other than that, your "question" in fact *is* a little bit too vague for me I hope this already helped a little bit and would very willingly help more if I knew how to...
Regards, Ilja

[Frank Carver]

Another tip: For your projects try to get an "as real" customer as possible - that is, someone who tries to get as much value from the limited resources of the team as possible, while working with conflicting and reacting to changing forces.
I'd like to reiterate this. The real skill in project management is mostly political. Sure, understanding development methodologies, progress tracking, risk analysis and so on are great tools, but more projects fail for political than technical reasons.
You can see this by looking at almost any volunteer project (there have been plenty here, for example). At the start everyone agrees its technically possible, but what almost always breaks first is the commitment, agreement and understanding of the team members. I would be very wary of assuming you can learn much about real project management on a volunteer, when-we-get-around-to-it, basis.
Who's going to roleplay the "pointy-haired boss"; who's going to roleplay the "just here to get paid" team member? Who's going to roleplay the panicky shareholders and out-of-touch CEO ? All of these (and how you deal with them) have potentially much greater impact on project management than which methodology you choose.
I hope you don't think I'm being cynical, or have missed your point, but for this to really work as a learning excercise, I think the project you choose has to really matter to someone (Ilja's customer, for example) in the real world.

[Dirk Schreckmann]

Those are excellent points, thank you both.
Those are issues we should better understand and discuss. Of course, I don't think that completely negates any benefits derived from gaining an understanding of the different methodologies in use. On that note, I'll also discuss briefly the SDLC a bit.
As a voluntary group, we won't have the same politics to contend with that a paid group would have, but we will have our share of issues to negotiate.

[Dirk Schreckmann]

...and let me welcome any comments as to why such groups have failed or will always fail or are likely to fail.

[Ilja Preuss]

Originally posted by Dirk Schreckmann:
...and let me welcome any comments as to why such groups have failed or will always fail or are likely to fail.

Well, it's oviously lack of motivation, isn't it...?
I think most developers want to be proud about their working product. And to be proud about it, they need to *experience* that it is usefull to someone. If they think that noone will ever really use the system under development, they will most likely loose interest quickly.

[Ilja Preuss]

As I think about it, all the above seems to suggest that you should try hard to get to do *real* projects.
Perhaps you could find some voluntary projects of public utility?

[Frank Carver]

Motivation is a complex thing. For anyone to spend a lot of time on a task, that task has to spend a lot of time at the top of their personal priorities list (however that is managed). The more "important" things you have to do which compete for your time, the less chance any given project has of reaching completion.
Some people can be so single-minded that they always complete one task before starting another, but that approach has lots of its own problems! The main way people seem to cope with this and get things finished is for the project to somehow "trump" most other priorities. Doing what your boss says during working hours is a prime example of this. If you don't, you could lose your job and/or income!
So the question for volunteer projects becomes one of finding how to make the project important enough to the people involved for it to actually spend time on it, and really care about finishing it. It's real hard. What seems important in the excitment of starting something, rarely appears so after a few weeks of missed opportunities. And what happens when another shiny new volunteer project grabs your attention, and your time?

[Dirk Schreckmann]

Thank you both for the excellent information and import considerations. We have embarked and I am certain that we'll successfully navigate the labyrinth of politics, motivation, and problems that lay before us.
I believe that by immediately addressing problems as they arise, and by constantly discussing our motivations and our sense of what we are doing and why, we'll develop and maintain a strong, cohesive sense of group purpose (identity/agency) which is vital to any organization.

[Frank Carver]

Good luck.. Let us know how you get on!

[Fintan Conway]

Originally posted by Dirk Schreckmann:
I believe that by immediately addressing problems as they arise, and by constantly discussing our motivations and our sense of what we are doing and why, we'll develop and maintain a strong, cohesive sense of group purpose (identity/agency) which is vital to any organization.

Hi Dirk,
The processes that you use and (perhaps more importantly) the committment to follow the processes are the keystones to successful Project (Management?).
Each methodology you are looking at follow slightly different (though sometimes similar) processes. If you examine each process with your team and determine which process is the most suitable for your organisation. Then you need a committment that people will follow the chosen processes, e.g. have test scripts written before rushing into coding.
What you may find is that some of the processes in each methodology are the best fit and you will mix and match processes from each.
As long as people follow the chosen process the project should succeed. This does not mean that processes should not be changed, but there needs to be an agreed process for moving from one way of doing things to another.
Regards,
Fintan