I was recently confronted with very interesting misconception: that Agile and SCRUM are the same thing. It really got me thinking. First, it means that one must be very careful when using the word “agile” in software development context. Less obvious: SCRUM is de facto standard agile method today, and very often the only one people know or heard about.

Wikipedia lists 10+ different methods falling under “Agile” umbrella. It’s no suprise because agile manifesto is very vague and does not really tell much (if anything) about the how part. Specific methods declared as “agile” are simply inspired by these principles. Agile software development is a way of thinking, or even a philosophy, developed as a reaction to shortcomings of “traditional” methods. While this religious/flamewar flavour may sound dangerous, it’s a fact that SCRUM (as an example) solves some of these shortcomings in a very neat and precise way. But is Agile any better?

Short answer: Typically, any method is better than no method at all (sometimes called DWYW - Do Whatever You Want method). Even shorter answer: it depends. Now the trick question: What is your definition of “better”? Then comes even tougher part. Here are some question about the company, team, project that you might want to think about for a while:

• What is your organization strategy?
• What is your current software development process, if any?
• What are the deficiencies of the existing process that make you think about adopting an agile method?
• What is the problem you are trying to solve?
• What is the problem domain?
• Do you have domain experts on site? Is the customer willing to provide them? On what terms?
• Is the problem repeatable?
• Who is your customer? Is it internal or external customer? Is the customer willing to work in a specific way?
• Do you have a fixed budget and/or amount of time available?
• Can you accept failure? to put in other words: what is your risk aversion?
• What do you consider be a failure?
• How well are the requirements defined?
• How likely are the requirements to change, and by how much?
• Are there any other cosiderations (i.e. security, outsourcing, legal) that are relevant to an organization or specific project?

I could go on and on. If you noticed that these questions are hardly technical, good for you :) The most important takeaway here is very simple: software development does not ever exist in a vacuum! The primary goal of any development team is to meet the needs of customers (and, by proxy, the business as a whole) and do it in the most efficient way. This is the only metric that really matters, because ultimately companies exist to make money, and without customers they cannot. Everything else is secondary. If waterfall development is the answer, by all means go for it. If not, go with something else. It’s a business, not religion!

I do not believe there is “one method to rule them all”, or that there will ever be one. Having said that, assuming specific company, market, team, project, etc etc, there definitely exists some perfect process for that composition. At the same time, you probably will not be able to identify and introduce it for very simple reason: by the time you do, the world will change. So, instead of thinking about what’s better in principle start thinking about what’s better right here, right now. Start thinking about agile process development.