If waterfall is so bad, why has it been in use for so long? If Agile is so good, why wasn't it used from the start?

Hi Adiv!

Great questions as always! Here's my thoughts.

I think it might help to view this as an evolution. Agile was created by those exact first generation software developers wanting to make a change in how the process was working, because their were flaws. It's an evolution of sorts.

If so, how was software ever updated?

Ever use Microsoft Windows 95 in 2000? ;) Long process to make seemingly small changes all released at once.

If the customer has to do some of the work that they're paying the team to do, they can rightfully demand a discounted price, no?

This work in different development practices is also required, usually just up front through specification documents and verification. This work , in my experience, is almost always approached with open arms as they can change things early and often. The work spreads out over the lifetime of the project instead of when it is too late or too early.

Hope that helps!

"If waterfall is so bad, why has it been in use for so long? If Agile is so good, why wasn't it used from the start?"

Waterfall isn't so bad for other fields, and in the very very beginning it wasn't used, the department was so small that cross team collaboration was a must there was only 5 guys who understood how computers worked. When the department grew they tried to shoe horn it into a previously used system, which wasn't healthy for the product.

"Didn't the first generation of software developers understand the issues that Agile is purported to address?"

Yes and it worked out well enough, clients would have to talk to the programmers themselves but as you quickly learn this is a jargon filled area so dealing with clients who knew nothing about what computer could do or what they wanted was a problem. So to get rid of the breakdown in communication there needed to be someone in between, the Manager boss person from waterfall filled in and thats how we got to where we did.

"Is the waterfall method really as inflexible as portrayed in the presentation? If so, how was software ever updated? How does a waterfall shop deal with changing specifications or objectives for the software it builds?"

In a traditional waterfall method the client would come into the company and they would negotiate terms on the product. I want ABC and the client would get ABC no matter what else came up. So if the client a week later came back saying "I don't need A I need D" they were out of luck. They could set up another contract to get D put into the product but that's a long time.

"If the customer is paying a team to develop software why must they also do work to get the product out the door? If the customer has to do some of the work that they're paying the team to do, they can rightfully demand a discounted price, no?"

The customer isn't doing work as much as being involved in the creation of the product so that the developers can understand what it's being used for. They want the product to be as useful for the client as possible and the only person who knows what's the most useful for the client is, well, the client.

I hope this helps. Mark

Waterfall is excellent for time tested repeatable projects. Its still actively being used in construction projects and turnkey projects where the process is highly predictable due to experience. Agile on the other hand is excellent for software development where a lot of unknowns are usually in place when the project begins, requirements change, competition steps up the game and you will always need an agile methodology to respond. like someone said above, look at it ike some sort of evolutionary trend. Cheers

I'm newbie here but when I started managing project, I was given simple project and I was practicing waterfall method. It is quite efficient and fast to deliver. But then I moved up to middle level project, then I used sprint method, and so on. The conclusion is IMHO, waterfall suits simple project and better that way.