There’s a very serious problem with choosing a methodology on a “per-project” basis, which is that most Agile methodologies reject the notion of projects.

A project implies fixed scope and fixed time, and for many of the more dysfunctional organizations, also a fixed budget. This is anathema to every methodology out there.

Every role, every tool and every ritual in a process like Scrum centers around the product – not a “project”. You have a product backlog which states what must be done and in what order (but not when or how). You have a product owner who chooses what goes on the backlog. You have product demos or showcases to inform the business of progress. You have product releases and iterations. Even your very first release is called the “Minimum Viable Product”, and it’s not intended to be the final release.

The closest analogy to a traditional “project” would probably be a single sprint/iteration/cycle, because at the end of a sprint, your team should have come up with one or several meaningful improvements to the product that deliver some measurable business value. If your team isn’t doing this, your team isn’t Agile in the capital-A sense of the word. If your team isn’t dedicated to a single product (or maybe a small suite) then it isn’t Agile. If people outside your team dictate requirements or deadlines to your team, then your business isn’t Agile.

I am not saying that you have to be Agile. What I am saying, however, is that you can’t really pick and choose. Most of the “good” Agile methodologies like Scrum include process improvement as part of the process itself (i.e. retrospectives and post-mortems), thus I am also not saying that your process should be static. To the contrary, unless everything went absolutely perfectly during your last few sprints, you should probably be tweaking the process. But Agile processes are processes for continuous delivery, and if you switch to “project” mode at any point, then you’re throwing away the continuous part and you might as well just stick to a more traditional project-management process. Not waterfall, which was broken even according to Royce, but something more formal like the RUP.

In general I would say it’s OK to have some Agile teams and some non-Agile teams/projects if they are different teams. I’ve seen what happens when businesses try to shoehorn waterfall projects into an Agile team/process, and rest assured it’s not pretty; at best it seriously hurts the quality and timeline of both goals, at worst it will drive the team members so crazy that half of them quit. Avoid, if possible.

I don’t see the benefit of trying to do everything the same unless you’re willing to turn-down projects that don’t fit your particular model. Otherwise, you get a bad fit and the client isn’t going to be happy either way.

If you’re so sure you know the specs in one case and are very confident they won’t change, you can still run it as an agile project. Just because Agile is better when specs are vague, doesn’t mean it is useless when they are solid.

Keep things as consistent as possible so you can have members work on different projects without too much adaptation of the general method. People are better at making adaptations when they fully understand what it is they are adapting; otherwise, it’s just chaos. Of course, this assumes all your clients are willing to work under an agile methodology.

Agile vs Waterfall its not only about have a set requirements up front. There are other agile values aside from responding to change, for example:

• People more important than process.
• Deploy software that works in short iterations.

If your company is agile i cannot see how you can abandon this agility for one project, agile its much more about a mindset and core values than about concrete practiques. If for a project do you have solid requirements that don’t change you can still work on this projects with your agile values and mindset. Go in small iterations, empower your team, show software that works frequently… with agile you are prepared to change, if change don’t appears you are off course prepared to this too.

In my experience, most organizations use a mix of the processes that work best for it and its customers (business). While Agility is an organizational goal, that does not mean ALL its software projects need to be run using an Agile method (Scrum or others). Agility means being able to respond to change quickly and still deliver quality products and services that meet the customers’ requirements and thus organizational goals. That can be achieved with a variety of methods and approaches by the organization.

I would rather ask the question – what is the problem that you are trying to solve? Is there a problem? Does the solution require changing or examining your software development processes? Is the solution to that problem to get everyone on the same methodology?

Even so, I can assure you that most organizations today have ‘agility’ as a business goal in some fashion or the other – AND work with a variety of software development methods depending on the needs of the customer, the nature of the project and the skills and maturity of the team involved.

Hope that helps!