Based on this question about alternatives to the agile philosophy and its answers and comments I thought it might be useful to discuss what goes into the decision of what "methodology" to use when at the start of the project.
Seems the consensus is that if what you are building requires exact specifications that waterfall is the way to go over agile. That seems to leave a HUGE space for agile development. Beyond "this is how are shop develops software" are there questions or "indicators" at the early planning stage that might give a better indication of what might work best for the client/project?
Like with languages the idea is best tool for the job so as professional developers what do you do to make sure you're using the correct development methodology for a project you're about to start?
Is it really as cut and dry as "if it's a bridge or nuke reactor type project use waterfall else use agile?
I am a self taught programmer working for company that gives a lot of flexibility and they put a lot of trust in me so this kind of question is important to me. I want to make sure I am addressing my work/projects in the most efficient cost/time manner as possible.
Best Answer
First, it's not a choice of waterfall or agile, but plan-driven versus agile. There are many plan-driven methodologies to choose from. The other prominate plan-driven methodology is Boehm's Spiral Model. It's iterative development, but it's not (necessarily) incremental. I asked a question about other plan-driven methods, and the other one that was indicated was Cap Gemini SDM.
When you are deciding between a plan-driven methodology and an agile methodology, there are a number of factors to consider. In Rapid Development: Taming Wild Software Schedules, Steve McConnell has an entire section devoted to chosing a lifecycle model. He looks at a number of lifecycle models - pure waterfall, code-and-fix, spiral, modified waterfalls, evolutionary prototyping, staged delivery, evolutionary delivery, design-to-schedule, design-to-tools, and COTS software. Each is discussed in depth, and assessed on its ability to cope with poorly understood requirements, to produce a reliable system, to manage risk, to fit within a constrained schedule or budget, to provide visibility to customers and/or management, and the sophistication of the team.
So, yes, one consideration is the type of project that is being delivered. But there are numerous factors and many lifecycle models that can be chosen from.