The Agile Dogma 

Dogma :: "prescribed doctrine proclaimed as unquestionably true by aparticular group"

In the recent years I worked both under the waterfall-dogma and under the Agile-dogma.

I have come to three conclusion:

1. Both Dogmas are wrong as a dogma.
2. Both have valid use-case for particular projects.
3. Most developers don`t understand the difference between prototyping methodology and product-development methodology. Agile is the second, not the first.

When you start a new software project, you need to decide which product-prototyping method is right for you and then which software-development dogma is the right for the project. Choosing the wrong one is a clear path to failure, so choose wisely.

Step 1: You think you have a great product-idea. How can you know it`s indeed a great one.

First ask yourself, is my idea is a bright new product which was never commercially tried before (GPS-enabled Sun-glasses) or is it only a small improvement on an existing successful product
( new email client )

• If it`s a new product - you must create a minimal prototype to test if it will actual sell.  It should be very fast - up to a month`s work.  Agile/Waterfall do not apply for such short time frame. 
• If it`s an incarnation of an exiting product - great! someone else already "prototyped it" for you. Fill free to use their product to and jump to the next stage.

Step 2:  You verified the idea and shown a prototype which people love.  Should you have one public-release or a lot of small public-releases?

1. What is the use-pattern of your product?Is it a "use-once"(a movie) , "use-for-few-weeks"(most games) or "continues-yearly-use" (most websites) ?  
2. Can an existing user get the new version of  the product very easily?
   Is it automatic(a website), a manual-update (mobile-app) or plain-impossible(firmware,hardware)

If the answer is a clear "YES" to both of the questions above, go for multiple-releases.

If the answer is no even to one,  you need one big release (didn`t talk about agile/waterfall yet)

Let`s see some samples:

• For a web-site like an online-store/news-site the answer for both is a clearest yes. The users use your site on a continues-yearly-use and each time a user enters the site he will get the new version automatically.
• For a media (movie/presentation) the answer is a clear no, as most of the users will see the movie once in the first month and will not bother to re-view it once you release a new version.
• For downloadable game, the answer is a clear no. Although most game have an auto-update feature for bug-fixes, most users will play the game only in the first month. 
• For firmware for hardware-devices the answer is usually no. Although the user use in continually  99% of the users won`t upgrade the firmware version.
• For a software library (like logging framework) the answer is again a clear no.  Other developers will not update your library automatically, and will usually do it once  a year, when they need an extra feature the new version has.

If you answered no to one of the above, you need to have one ultimate public-release
But, on some products , you can still have multiple "closed-beta releases".

1. First find a large pool of  "beta" users which you can ship your product too. They should be the typical audience , but their size should be up to 1% of the intended users. (You can pay them)
2. Divide them to multiple distinct groups.  If you plan around 5 iterations, create 5-8 groups.
3. In the end of each iteration, use one "fresh" group and get it`s feedback. You will not reuse that group again
4. In the last iteration , release to the general public.

The large pool of users is a must. Using the same person all the time, usually your product-manager or in small-startup`s your spouse, gives very bad results.

Sometimes you can`t find any users which will test your product. In this case you can still create internal-releases or internal milestones in which each feature is finished and ready to be internally tested. This is true to both agile and waterfall approaches.

The obvious Bottom line is "NEVER DO THE FIRST-TEST JUST BEFORE PUBLIC RELEASE".  You will be surprised how many companies do just that.

Step 3:  You know how many releases you can do.  What software principle should you use?

All software products can be separated into multiple small independent features. This is true if you are building a algorithmic-focus search-engine , or a design-focus web-site.

So first divide it to these features and work on them.

Waterfall is great if it is done on one small feature. Meaning you will spend a 1 day on design, 3 days on development&unit-testing ,and then 1 days on system-testing.

But what of the features that take few months to develop?

Well, first try again to break them into sub-features, most features can be broken with enough thought.

If you really can`t , and it`s rare and usually limited to algorithm-intensive or framework-intensive work, then go waterfall on this particular feature.  Let me emphasize that these kind of features are very-rare in web/media/mobile products and most developers today should do it very rarely.

So bottom line here, design+implement+test in the waterfall way is good as long as it is for small features. (some will say this actual == most-of-agile)