Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.
share|improve this question
There is no good development method if you choose to hire people with no domain knowledge, or with limited skills in programming. – David Hammen Nov 27 '12 at 14:18
up vote 2 down vote accepted

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 (, 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).

share|improve this answer

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.

share|improve this answer
Thanks for the book, I actually hoped for an answer that explains some of the stuff you mentioned. Could you put a short list? Or is that too much for one answer? – Kahil Nov 27 '12 at 14:43
@Martin I can't right now, but I can try to revisit this question later. It won't be comprehensive, since only a handful of models are discussed in Rapid Development and there's no way to discuss every model in an answer. I'm just not sure how useful it would be, though, due to the sheer number of variables. I have a feeling that there are books (such as Rapid Development, and others that it cites) that can do a far better job explaining it than I can in an answer here. Is there anything in particular that you want explained? – Thomas Owens Nov 27 '12 at 14:49
No, I'm studying this in a university course, and just had a debate with my instructor, and I didn't like her answer. I'll be happy if you revisit the answer later. Thanks any way :) +1 – Kahil Nov 27 '12 at 14:54
+1 The customer can be a huge influence, in particular what they want as deliverables and when. – jk. Dec 10 '12 at 13:30
@Martin I started to work on updating this, but it was just turning into something way too complicated for an answer on Stack Exchange. Steve McConnell breaks it down as simple as I think it gets (or at least as I can explain it) in an entire chapter of Rapid Development. It's just a matter of understanding how each process deals with the project characteristics I mentioned and choosing the best one for the project and the team. – Thomas Owens Dec 10 '12 at 13:34

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.