David Bland at the Agile Zone has an interesting take on the old ‘waterfall is evil’ mantra that I hear all the time.
Basically, it works like this:
Waterfall works well when both the problem and the solution are known.
For me, this would be the situation when you are dealing with subject matter experts and you have an out-of-the-box solution. The absolutely key point here though, is that the requirements are blindingly obvious, and the SMEs can summarise the problem succinctly.
Waterfall works well when both the problem and the solution are mostly known.
For this to work, you’ll need to keep a very close eye on the scope and the problem at hand. The requirements can quickly become a Christmas wishlist otherwise, and I believe it is these sorts of projects which are the ones that bring Waterfall a bad name.
Agile works well when the problem is mostly known and the solution is mostly known.
So this is the same thing as the previous example. And like David says, you can use either here, depending on your preferences.
Agile works well when the problem is mostly known and the solution is mostly unknown.
I’d say that this is the perfect use for an Agile approach. Here you can keep your final deliverables vague to start with, and firm them up as the solution identifies itself.
Agile works well when the problem is mostly unknown and the solution is mostly unknown.
Holy moley this one scares me. I’d suggest that you need to have some indepth discussions with the business, find out what their business rules are, what the expected benefits are, and then decide if there’s a problem here to fix.
With the exception of the first example where experts can preclude the need for requirements, it would seem that the decision to go Agile or Waterfall would require a decent requirements gathering phase, to decide what the best tool for the job is. People pre-determining the approach is a recipe for disaster.