Once again, I am comparing these three approaches to software development. It might seem funny that I could treat “cowboy” like it is a real methodology, but there is some reality to it and I would like to explain how & why it works.
First, let’s compare how each one handles requirements:
Waterfall – You gather all of your requirements before you start developing. Hopefully, you can gather them all correctly, so the project comes-out perfect at the end. It only seems to work if you have skilled & experienced requirements takers and givers. Even then, you need some amazing luck, or low standards or something. Otherwise, at the end, you will discover all of the stuff that you missed, or got wrong. For this reason, people often refer to waterfall as “water-fail”. Of course, that nickname is only funny if you haven’t been burned by it, or your scars have healed.
Agile – You gather some requirements and start working with the ones you have. As the developers are working, the business analysts gather more requirements. You get short bursts of work done, at which time, you discover which requirements were wrong or incomplete. You add those into the next development cycle. Your cycles need to be rather small (1/2 – 2 months for each dev cycle). After failing and correcting enough times, you eventually are likely to get everything right. YMMV.
Cowboy – You don’t really know how to gather requirements. You just take your best guess and start writing a program. Once you have enough working, you show it to the customer/users. They try to figure out how to use your program and give you feedback about what is not working or is awkward, or insufferable. You can’t easily distinguish between which ones are bugs and which are requirements. It doesn’t really matter because it is all part of your “to do” list. Once your “to do” list is empty, you are done.
There is one common thread between all three of these. They all gather requirements and do testing. Some are more formal, and optimistic about their ability to gather requirements. Others are (perhaps) more realistic, and acknowledge that the end-users are going to see some bugs.
The big differentiators are 1) how good are you going to be at giving/getting requirements, and 2) who does the most testing and catches the most bugs.
The funny thing is that, in reality, Waterfall usually reverts to cowboy at the end. Cowboy usually starts with a mini-waterfall and Agile seems to rock back-and-forth between mini-waterfall and mini-cowboy. In fact, most agile projects are mostly mini-waterfall or extra-fancy cowboy.
My point is this: Plenty of teams are able to be successful (to varying degrees) with each of these. The key is to know your strengths and pick an approach that plays to your strengths. The biggest cause for failing at one of these, is thinking that you are the wrong one, and struggling to avoid the way which fits you best.