How to choose a development method?

Question

There are many academic/industrial researchs about various development methods (Scrum, XP, waterfall, ect.), telling us how to do it right and stuff. But I never saw something that suggest how to choose a method, what will be better for a given project.

I know that what the developers are used to is an very important aspect. But lets say that I am assembling a new group from scratch, and that every programmer in the world is willing to work with me. :)

What aspects of the project should I consider to decide between Scrum, XP, TDD, ect.? Or is that an entirely human thing, regardless of what is being developed?

• I said that all programmers are available, but you may comment they're knowledge about the domain, or other characteristics in the answers. E.g. "If you chose to hire people with no domain knowledge, MethodX is better than MathodY, beacause ...." is a completely welcomed answer.

Answer 1

There is something like a continuum between agile methods and the old, rigid, strongly formal "waterfall" approach. The more you walk away from agile developement, the more you add structure and design to your development process.

This means that moving closer to a waterfall model, you will need more knowledgable designers, more knowledgable programmers and more knwoledgable project managers. More important, the closer you move to a waterfall model, the more you need knowledgable customers.

Customers are probably the deciding factor. If you have a customer that does not actually know what he/she really need or want, you are practically forced to adopt a development model that is able to accomodate for a large amount of change. This is usually the case for web development, for example. If you have a strongly technical, mature, knowledgable customer, as is usually the case in the embedded development field, you are usually requested to adopt a strongly formal method (something like a waterfall).

Programmers are another major selection point. You cannot actually adopt a strongly formal method with a group of college part-time workers. The more you need a formal approach ("waterfall" as an extreme example), the more you will need seasoned programmers with a large and strong set of skills.

The type of system being developed is less relevant. There are web application so complex they need a development model very similar to the one used by NASA to go on the Moon (Amazon.com, for example) and embedded systems so simple that a single college programmer can develop it in a few weeks alone with any dev method at all (like many Arduino-based toy projects).

Despite this, usually the systems that imply some kind of hardware dependency (embedded systems of any type) require a strongly formal approach because any error will be paied in $ or € by the developing company.

This is another continuum: the more you walk away form hardware, the less you need a formal approach. The more you move away from money-related stuff (bank systems, e-commerce systems, POS, etc.), the more you can have an agile, iteractive approach. The limit is probably represented by the typical web-based brochureware where you do not actually need any formal approach to development (as long as you have mature and conscientious people).

Answer 2

In Rapid Development, Steve McConnell writes about choosing an appropriate lifecycle model for your project. There's an entire section of a chapter devoted to this topic, but it comes down to the characteristics of the project - the level of understanding of the requirements, the level of understanding of the architecture, the required reliability, the amount and severity of risks, the schedule and budget constraints, desired customer and/or management visibility, and the skill/sophistication of the project team are identified as the major selections.

The type of system has very little to do with it, although that does frequently play into the reliability or future tendency to modify/enhance the system). The people are your biggest drivers in terms of how well they understand the domain, the tools, the project, and what the interaction is between the development team and other stakeholders. Knowledge of the process is also important as there's overhead in learning new techniques to doing work.

Answer 3

I suggest you try the Process Consultant at OPFRO web site. Click on "Process Consultant" on the left-hand side menu and answer the multiple-choice questions about your needs. The tool will recommend a method life cycle. You will also see some explanation about why that is the best option.