How do you evaluate if the Agile method is the right one for a specific project?

Question

I am looking for an evaluation method and criteria for determining if a project can be conducted using the Agile method (over traditional/waterfall). I would welcome examples ("definitely Agile", "definitely not").

Answer 1

My experience in project management so far has been only in software engineering and therefore I will try to answer from that perspective only.

The best place to use Agile is where you are expecting changes in the future. Since agile is lightweight and welcome changes, you may be in a better position to respond to changes (market demands, requirements change, feature updates etc) if you use agile.

As agile guru Martin Fowler suggest http://martinfowler.com/articles/newMethodology.html#ShouldYouGoAgile moving to agile also requires a mindset change from all stakeholders and will be succesfull only if everybody is fully committed.

Also to continue to stay agile requires a lot of discipline (follow continuous re-factoring, TDD etc)

That leaves us with is Waterfall dead or is there still are some valid case for waterfall. My view is projects or disciplines where requirements are not expected to change, projects where a lot of initial analysis and design is required are still good candidates for waterfall.

Answer 2

To do Waterfall, you have to have a reasonable certainty of getting things right up front.

Because of this, you can only do projects which are very low risk, ie: ones where the vast majority of it has been done before. See "Waltzing with Bears", Tom de Marco and Timothy Lister, for why these projects may not be particularly useful, especially in software development.

Agile isn't just about keeping things responsive to change. It's also about keeping things responsive to learning, so in any situation where you've got a high amount of unknowns - people who've never used the technology before, or a new GUI that hasn't been tried, or an architecture that might not work with the legacy app - I would use Agile. Many of the traditional Agile practices, like stand-ups, showcases, retrospectives, etc. are there to get feedback, learn from that feedback, and share the learning, thus reducing the risk.

Even on a project where the requirements have been analyzed to death, the chances are that learning and discovery will be taking place. Agile practices which allow that learning to be shared can then be useful, even if the analysis practices are discarded.

The only danger of this is the transparency which it introduces, which often causes the people who asked for the requirements to ask for changes, in which case you should probably have gone with something a bit more Agile...

Some examples:

• Configuring and installing a standard business package: Waterfall. Get the experts in to do it, don't do it yourself, or if you do, use Agile.
• Greenfield project with no existing codebase: Agile.
• Incremental move from legacy app: Agile.
• Complete rewrite of legacy app: Agile.
• Small changes to existing app: Agile*.
• Fixed price, scope, budget: Waterfall might protect you a bit, maybe, but you'll still benefit from Agile learning practices.

*This is actually a good one to start Kanban with, which is related to Lean rather than Agile. Most stuff is suitable for Kanban if it's suitable for Agile methodologies anyway; they have more in common than different.

Answer 3

There are two areas which I would consider waterfall most appropriate. This will be expensive to produce, and should have a fully functional change management process.

• Highly regulated software where software must be to specifications, and all changes controlled.
• Software where failure may be deadly (aircraft fly-by-wire software, nuclear reactor control systems, medical systems, etc.). All changes will need to be approved.

A third case where waterfall might be appropriate would be a project with low risk, and known solution. Most of these should be candidates for off-the shelf software. These project might benefit from some use of agile processes.

At this point in my career, I would consider most other projects as candidates for Agile processes. Things that I would classify as definitely Agile include:

• Highly competitive environments. (May need to release new version on short notice.
• Projects with a high degree of uncertainty. Agile techniques can be used to drive towards certainty.
• Projects with lots of nice to haves. Develop core functionality, and add nice to haves based on priority or discovered importance. It makes it easier to delay non-core functionality until needed.

Look to the other methodology for things that will increase your certainty. Agile can be used to clarify areas of uncertainty or risk for a waterfall methodology. Waterfall can provide a stable platform underneath an Agile project.

One of the areas I have seen lacking in many projects is a good base to develop from. I would expect a consulting organization to have defaults for these, but I haven't seen it in practice. This includes things like:

• Choice of tools where important: language(s), database(s), hardware platform(s), version control, change/bug tracking, etc.
• Organizational/project standards and best practices.
• Team organization, roles, and backup resources.

Answer 4

See the diagram on page 3 of this classic: Balancing Agility and Discipline by Barry Boehm - http://agile2003.agilealliance.org/files/P4Paper.pdf

You have 5 dimensions: Personnel, Criticality, Culture, Size, Dynamism. It's more like '5 dimensional' graph and the 'size' of the polygon should give you a visual que if Agile is more suitable or Process intensive. You can increase the number of dimensions are per your company's view point and add more dimensions...