Choosing Between Agile and Waterfall: Indicators

How do you know how agile to be in your software development process? Or how rigid?

If you have developed any software, you are probably familiar with pros and cons of both agile and waterfall processes, and you probably understand that agile and waterfall are on a continuum of sorts -- that is, there are shades in between. Even a continuum may be simplistic, because human processes are complex and multidimensional.

Therefore I will write in terms of processes that are "more agile" vs. "more waterfall." To be clear, by a more agile process I mean one more likely to include iteration, lightweight requirements, automated testing, a flexible schedule, and emphasis on continual team communication. By a more waterfall process I mean one more likely to include rigid and detailed requirements, less automation, a predefined schedule, and more restrained communication.

My goal for this entry is to lay out some rules of thumb, or imperfect guidelines, to help you choose a process that is more agile or more waterfall, depending on the circumstances. Because these are rules of thumb, you may need to consider the various factors independently and weight them as appropriate for your project.

Indicators for Agile

In other words, you might want to use a more agile process if...

• Your customer trusts you.
• You are developing a service.
• You are developing for multiple customers.
• There is no single contract between you and your customer.
  
• There is an expectation of maintenance.
• Your customer is more flexible.
• You have a flexible or unknown deadline.
• You are developing a new or innovative sort of product or service.
• Your customer doesn't know the requirements well.

Indicators for Waterfall

In other words, you might want to use a more waterfall process if...

• Your customer doesn't trust you.
• You are developing a one-off, shrink-wrapped product.
• You are developing for a single customer.
• You are developing for a single contract.
  
• There is no expectation of maintenance.
• Your customer is less flexible.
• You have a rigid deadline.
• You are developing a standard or well-known sort of product or service.
• Your customer knows the requirements well.

Again, the indicators are not absolute. For example, a more agile process can still work very well, and sometimes better than waterfall, with a rigid deadline. But I list a rigid deadline as an indicator for waterfall because an agile process can be even more helpful when the deadline is flexible or unknown, whereas a waterfall process does not usually work well with a flexible deadline.

I list trust first because it can be a very powerful indicator. Even if most other indicators point to waterfall, a high degree of customer trust can enable a more agile process. I feel comfortable saying this because I have personal experience with it.