The way people define Agile is somewhat similar. Depending on which part you touch, you may come away with a different impression of what Agile is:
- Many people will define Agile in terms of how it is done. For example, many people will say that it is defined by the Agile Manifesto. Here are a couple of examples of that:
“Agile is a set of methods and frameworks that embody the principles and values of the [removed]
“Agile is a term used to describe approaches to software development emphasizing incremental delivery, team collaboration, continual planning, and continual learning. The term “Agile” was coined in 2001 in the [removed] .”
- Some people will say that it is just a mindset or way of thinking. Here’s an example of that.
“Being ‘Agile Is a mindset. It’s about finding the right thing to build, faster (and not just building things faster)”
- Some people will define it by comparing it to “Waterfall” to tell you what it is not. Here’s an example of that:
“Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.”
None of those definitions are incorrect, but it’s like “feeling the elephant”; they don’t really get to the real essence of what the “elephant” is, in my opinion.
How Do You Define Agile?
Personally, I like the definition that is published by the Agile Alliance:
“The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”
I think that is a better definition because it gets to what I consider the real essence of what Agile is.
“Agile is best suited for situations that have some level of uncertainty where creativity and innovation are important to maximize the business value of the solution as opposed to other situations with lower levels of uncertainty where planning and control to achieve predictability are more important.” (My own definition)
What Problems Does Agile Solve?
We should acknowledge that Agile is not a solution to every problem you might have. One way to define it is in terms of what problems it is useful for.
- If you accept that Agile is not a solution to every problem you might have, the first thing you would want to know is “what problems is it useful for?”
- You don’t need to get too far into the mechanics of how to do it until you’ve determined that it is a useful solution to the problem you’re trying to solve.
There is an interesting observation you might draw from this – people get very immersed in the mechanics of how to do Agile and that’s how they define it. Isn’t it more important to know what problems it’s useful for solving before you get into the details of how to use it?