Is there a viable alternative to the agile development methodology?

Question

The two predominant software-development methodologies are waterfall and agile. When discussing these two, there is often much focus on the particular practices that distinguish them (pair programming, TDD, etc. vs. functional spec, big up-front design, etc.)

But the real differences are far deeper, in that these practices come from a philosophy.

Waterfall says: Change is costly, so it should be minimized.
Agile says: Change is inevitable, so make change cheap.

My question is, regardless of what you think of TDD or functional specs, is the waterfall development methodology really viable?

Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software? Or is the question really about what sort of practices work best in our situations to manage the inevitable change?

Answer 1

Of course waterfall is viable. It brought us to the moon!

And it's a agile coach talking here!

Unless you can clearly identify problems related to the way you manage your projects, there is no valid reason to change.

As an alternative of Agile and Waterfall methodologies, I will suggest YOUR methodology. Adapted to your specific business, your specific team, your products, you way of working, your company culture... It's why Scrum is called a simple framework instead of a methodology.

Wanting to implement a methodology because someone on a blog you like talked about it is as stupid as letting problems going without doing anything.

Answer 2

You begin by saying:

The two predominant software-development philosophies are waterfall and agile.

This is false. This dichotomy has been constructed by the agile community in order to create an opponent against which to position themselves. Before agile was in vogue, people used to speak about a myriad of different approaches to building software. They still exist today, but somehow they are often lumped together into a big mess called "waterfall" by agile proponents.

I have been using OPEN/Metis and its variants for over 10 years with great success. It is definitely not agile, and definitely not waterfall. Thousands of developers create extremely complex software for aircraft, life critical systems, banking, etc. using non-agile methods every day.

So yes, of course there is a viable alternative to agile.

Answer 3

First, I'm going to disagree with your statements:

Waterfall says: Change is costly, so it should be minimized.
Agile says: Change is inevitable, so make change cheap.

My interpretation is:

Waterfall says: The customer knows what they want.
Agile says: The customer doesn't know what they want so we're going to have to make a few different versions.

The best implementation of "waterfall" that I've ever seen was a huge integration project with a very large financial customer and there were about 40+ sub-projects involved. The desktop and website package we supplied was just 1 of those 40+ sub-projects. While I thought they blew through other people's money rather excessively, they had their stuff together and kept 40+ different ships all moving together in formation. The project went live on the target date (the target moved once during the project) and while I thought they could have done it more frugally and agily, it got done on time and on spec. The go-live night's schedule was about 100 pages long and about 40 of those pages were emergency panic contact details of all sorts of people involved. I was very impressed by this client.

Or, you could do what we do, which is run around and do what the most recent complaint/bug report is, and call that agile.

Answer 4

Yes, various software development techniques are all viable depending on your problem domain. It's "Horses for Courses".

For example, you're writing software to control a Nuclear power plant or to drive the NASA space shuttle. This sort of problem domain is probably better suited to a waterfall (or even stricter) approach, you want to sort out all of the issues up front if possible (or BOOM!).

Building the latest web 2.0/3.0/buzzy marketing term UI? Agile is a much better way to go (yo need that quick feedback and change).

There are what I would call software craftsmanship principles that can still be applied no matter waht the methodology is e.g:

• Source control
• build and CI
• pair programming
• TDD
• I give a ^%$$&

and more.

Whatever you do, don't listen to the zealots on either side of the equation, do what's right for you, your team and your problem domain.

Answer 5

The problem stems from the complexity of software. Waterfall works great for things like bridge building and road paving because physics just never changes. Sure, at some point we'll develop a new asphalt but it won't revolutionize the way roads are built. The steel in a bridge's suspension is either the right size, or it isn't. You can't kludge or stub a real construction project like you can with software.

Software changes. Software changes rapidly. Moore's law states that number of transistors on a chip doubles every 18-24 months. In corollary, the number of lines of code in a program also doubles. Complexity in between those lines of code therefore increases with a bigO of something like 2^(2t).

Software changes rapidly, and complexity increases exponentially with it.

When controlling the cost of the software, you want to control exponential factors, not just multiplicative or additive. Changing code increases the complexity (and gets exponentially more complex itself as the project moves on) in an exponential manner.

Change is inevitable. The very nature of programming extends the language with classes and custom methods, thus changing the language itself. You can't do that in any other kind of engineering discipline (like building roads. You don't invent new pavement just to pave a road in kansas over california).

The agile method also gives you a platform for handling future releases and bug fixes. You alredy have the management tools, processes, trained employees, for developing versioned software. With a waterfall method, you would need to retrain your team to handle even minor bug-fixes.

anyway, my 2 cents.

Answer 6

To answer the question, is there a viable alternative, for software perhaps not - or not yet, at least in the general case. I think it comes down to the nature of software. Software, being information, can be duplicated for free. Unlike a bridge or a house. This means, with practice, I could get good at building a house and be operating in a relatively simple domain. At which point why not use a one-shot approach?

But because software has zero duplication costs, why would you ever do the same thing twice? Software tends away from manufacturing. So if all software is the creating of new product then we're always operating in a complex domain where, to some extent, we don't know what we're doing. Or it's expensive to know up front and it's cheaper to find out by doing. In a complex, risky domain, I'd want to try experiments and increment and iterate.

Nuclear power stations and fly-by wire systems are often given as examples of software you'd want to do waterfall. But wasn't the shuttle avionics system developed iteratively? As was the Canadian and US air traffic control systems?

And if OPEN/Metis is iterative and incremental then, for me, it sounds like it has the agile philosophy even if it doesn't associate itself with other common agile practices.

Answer 7

The Waterfall method most certainly is viable and is as philosophically sound as any other approach. Remember that Waterfall has been around much longer than Agile, but note that this isn't an argument to state whether one methodology is better than another.

You use the Waterfall method when have a very clear understanding about the entire problem domain and what the customer wants to achieve in a software package. You've probably quoted a fixed price when taking on the contract, and your customer understands that they cannot deviate from any agreed requirements. Your process is strictly one that flows through a series of sign-offs between the various stages of development, and it is often the case that each stage is completed by a different team - sometimes even a different company - each of which may not necessarily in contact with the others. You often see Waterfall applied to good effect in military and government projects when they are tendered to outside contractors. Where Waterfall and other similar approaches get a bad reputation is when developers run into problems, such as poor estimation, schedules planned without contingency time, or a poor or incomplete understanding of the problem domain. The issue is never truly a fault of the methodology, but in the application of it.

The comparison between Agile and any methodology is a false one. Agile isn't a methodology, it's a philosophy, or perhaps it would be better to say that it is an umbrella term that represents a different way to look at how you go about developing software. A methodology is merely a tool, and as such its value will always be less than the individuals and interactions that are at the heart of what it means to be Agile.

Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software?

Every opportunity to minimize change is valuable to both the developer and the customer. Changes can cause a schedule to slip, or features to be left out in order to meet a schedule. It's how you manage the effects of change that impacts on the value of your projects.

Or is the question really about what sort of practices work best in our situations to manage the inevitable change?

Your practices may aid in the management of change, or they may ignore change completely. What matters is the combination of your development practices, and the management of your relationship with your customers, and whether these things work together effectively for all of the parties involved.

Those of us who are for all intents and purposes Agile understand that you choose a method that works for you. If you like particular approach, follow it. If it doesn't quite fit your needs, change it. How you go about crafting software really comes down to trying to make the best use of the resources you have at hand, and minimizing those practices that can lead your project towards failure, and you often find that you need to change your method to suit the particular project at hand.

It really is one thing to say "Ok, so now we are Agile", and totally another to actually live and work by the philosophy that Agile is. Whether you use Waterfall, Incremental, Spiral, SCRUM, XP, FDD, or any other method, you are basically Agile where you value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

and where you bring your tools, method, and your experience all together in order to apply these values successfully.

Answer 8

Yes, Waterfall, Spiral, Iterative and other hybrid process models are all viable, but change is inevitable. Process is more than just about how to handle change, and (I claim that) the biggest determinant is how well you know/understand the problem, and how accurately you can plan and predict.

Stating that "the two predominant software-development methodologies are waterfall and agile" is disingenous, as there is a spectrum of software development processes, and many companies synthesize their own version of the process model, often changing for a given project. There are more than two viable approaches to software development. Although Waterfall and Agile tend to fall on opposite ends of the "change" spectrum, it is reasonable to typify these competing methodologies as,

Waterfall says: Change is costly, so it should be minimized.

Agile says: Change is inevitable, so make change cheap.

But that is not the whole story. Business needs to be able to plan and predict, but software is a creative process, and estimates are often wrong. Remember the good - fast - cheap triangle? Add a fourth dimension, process, and you find that reducing process effort can also compress the schedule, when the estimates turn out to be wrong and a project is in danger of delay. Software is a fungible (mutable) process, and Agile, Iterative, Spiral all offer the ability to deliver incremental functionality in shorter intervals.

Waterfall and other requirements driven process models have controls for handling change, so it is inaccurate to say Waterfall minimizes change, it is more accurate to say Waterfall recognizes and manages change, and communicates the impact of that change (because change causes schedule impact when you have requirements and design up front). When you are building a product, or have need to fully-define requirements (functionality), you are driven to one of the hybrid models.

And when estimates are wrong, often process (the fourth leg of the iron triangle) is sacrificed to meet the schedule.

Answer 9

Mature agile and waterfall approaches are indistinguishable from each other. Your assumption about the goal of the waterfall approach is incorrect. They both have the goal of producing quality software. When you don't have a solid development approach for the company as a whole, you need to look at which approach will provide the least amount of friction to adoption. In the end short development cycles, a solid QA team, and a business that drives the development are what is most important to producing top notch software.