Waterfall or Scrum? And why?

[OscarG]

Well, now that the admin created this new section, I get to re-ask the question. What methodology should we use as we are updating our old suite of products. Also, if whoever answers can give some reasons!!!

Thank you

[BLarson]

The knee-jerk answer to that would be NOT waterfall, but I personally tend to think that there is never a clear-cut answer. One needs to consider each software development project individually and see what is best. Generally speaking, Scrum or some other Agile process is better suited for developing in today's fast changing environment. Having said that, depending on the project, certain requirements (regulatory conditions, licensing deadlines, etc.) may force one to revert to a more traditional process, similar to waterfall.

I usually create a matrix and put down conditions, requirements, schedules, etc. for a given project and then use that to decide what approach to take. And, most of the time, it ends up being some adaptation between Agile and Waterfall, even though if I had my choice it would always be Agile.

So, if you want to post additional details, one might be able to provide you a better answer. Or, at least *I* can try to do so.

Hope this makes sense.

[Andrew.Hillipar]

I agree with BLarson, there is no absolute rule, one has to look at it on a case-by-case basis. There are instances when a more "structured" approach is better for a specific project.

[Alex_Cohn]

I am not sure that the newer techniques are better! Agile promtes continuous delivery, which can be good for the client, but ends up creating lots of defects. In many agile projects I've been involved with, the defect list has grown faster than it can be dealt with, regardless of the good intentions of the team to take care of it.

Sure, defects are nothing new, they exist in every project, but agile seems to promote the practice of ignoring them.

[Derek_Thomas]

I am not sure that the newer techniques are better! Agile promtes continuous delivery, which can be good for the client, but ends up creating lots of defects. In many agile projects I've been involved with, the defect list has grown faster than it can be dealt with, regardless of the good intentions of the team to take care of it.

I would think this is more a function of the team and how well they adhere o principles. Agile does not promote or ignore defects. Whoever told you tha doesn't know much about Agile. Seriously, join a different better team so you can experience better, real Agile development!

[BillRotando]

Derek, aren't you just taking the easy way out of blaming the team instead of admitting that Agile may not be the "perfect" solution?

I don't claim to be an Agile believer, but I have also heard the horror stories of Agile being the VB of developers, i.e., allowing lousy code and allowing lots of things to be perpetually postponed in the name of finishing "something" on time.

BTW, if one looks at the published literature, it's full of examples of Agile having gone bad.

So, don;t blame the teams because they are not necessarily always the ones to blame. When an "unstructured" methodology like Agile is used, the results would tend to be unpredictable. It goes hand-in-hand.

[OscarG]

When I asked what methodology to use, I didn't meat to start a long term argument. I appreciate all the information being posted here, but I am having a hard time deciphering as to what methodology we should be using.

I've been reading on Agile and it seems to be a good methodology to use for "simpler" projects, but I am not sure about some of our more complex programs which may not be appropriate for development under a "flexible/adjustable" framework. The way I understand it is that Agile says "Why don't you focus on value. Instead of trying to get everything done and get people to sign off on all these requirements being completed, why don't you focus on the top value features..." And herein lies the problem as I see it. In some of our nuclear programs *ALL* of the requirements need to be met, completely checked and signed off, not just the top value features!

I haven't seen anything yet, in the various postings, that would address this concern and would help me answer the question of going agile or selecting a more traditional and more structured approach.

Not complaining, once again I appreciate all the info, I just don't find it very helpful, amongst all the arguing

I'll try and post some specific questions under separate headings, it might make it easier to get some help for me to decide which way to go.

[Alex_Cohn]

I am not sure that the newer techniques are better! Agile promtes continuous delivery, which can be good for the client, but ends up creating lots of defects. In many agile projects I've been involved with, the defect list has grown faster than it can be dealt with, regardless of the good intentions of the team to take care of it.

I would think this is more a function of the team and how well they adhere o principles. Agile does not promote or ignore defects. Whoever told you tha doesn't know much about Agile. Seriously, join a different better team so you can experience better, real Agile development!

That would make things convenient, wouldn't it?

I still think that many times (may be not always) the newer agile approaches add way too much process and not always enough "doing", so that teh project can be finished.