How do I go about choosing a development lifecycle model model?

Question

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.

Answer 1

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.

Answer 2

Is it really as cut and dry as "if it's a bridge or nuke reactor type project use waterfall else use agile?

Yes.

Actually it is that simple.

The point of Agile is to fit the process to the problem being solved.

The point of Waterfall is a (partly false) analogy between construction trades and software design and development. Construction (design everything first, build everything second) doesn't apply very well to software, because software is almost entirely a design exercise. There's little in software development that parallels conventional building or manufacturing.

Answer 3

It has a lot less to do with development methodologies being dominated by two schools of thought. It would be like asking if there is a difference between "Stiff, unbending, and rigid" vs. "Loose, flexible and ever changing". They are black and white, with an infinite variety of differing shades of gray.

Further within Agile there are a number of different templates to choose from Sources: Wikipedia:

• Agile Modeling
• Agile Unified Process (AUP)
• Dynamic Systems Development Method (DSDM)
• Essential Unified Process (EssUP)
• Exia Process (ExP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Open Unified Process (OpenUP)
• Scrum
• Crystal Clear
• Velocity tracking

Notice that I said Templates, because in reality every organization has unique needs that must be tailored to, and one of these templates can provide a good starting point. If this isn't enough choice for management to make the move to a sane and realistic method of software development that is grounded in reality then they are just dithering and paying lip service to the thought, and would go so far as to say that they are less concerned with writing quality software that fits the customer needs than they are about maintaining the illusion of firm and total control over their process and people.

Answer 4

IMHO, Waterfall doesn't suit any development, it comes from the construction industry, where redoing something is impossible (or at least, extremely expensive). But to software, redesigning and rewriting is cheap, and it is extremely preferable to review the specs continuously.

OTOH, Agile requires all team members to have approximately the same experience, and teams should be small, otherwise it adds considerable communication overhead. When the experience levels are disparate, it wastes a lot of time for the most experienced.

The approach I've used most, and which I have experienced as more effective, is to have no defined structure at all.

At first, projects require the most talented and skilled ones you can get, to have good foundations. You generally have nothing else to do, just put this people on the project and wait a few days, soon they will start organizing everything; it's the power of nature.

Just having the right people on the right place does the trick. Look for natural leaders (those everyone hates, yet loves). Once the thing starts to move they will switch into guardian-mode to keep things sane, and it will catch speed.

(Well, I admit there is an implicit structure, but it's highly dynamic)

The point is: development consists almost entirely (from this point of view) in social interactions, something extremely complex and resilient to careless intervention, so any attempt to design social interaction is doomed. The only thing we can do about it is to influence, slightly.

Answer 5

Mature agile and waterfall approaches look virtually in distinguishable from each other. Your main goal should be that the business drives the software development. It doesn't matter what model you use if you can't point to a feature and refer back to the business requirement for that feature. That is where QA comes in.

You need a solid QA environment that is the system of record for business requirements. QA stands for quality assurance, not testing. All of those tests that QA runs are to ensure that the system being built maps to the finalized requirements that are in their possession. And developers now have a direction to go when developing their software.

To make these things work well with the development team. You need to have short release cycles so that the business does not get overwhelmed with making decisions about what should be developed next. Also QA will have a better chance of determining if a specific feature does what it is supposed to do, and the feedback to the development team will be more specific because there are less assumptions about what is or isn't breaking that part of the system.

All of these things go towards making quality software. The development methodology is what glues them together into a cohesive solution that allows everyone to work together in a predictable manner. The waterfall approach tends to start out with the business having an easier time of adapting, where as the agile approach is more developer focused. But the both meet in the middle eventually.