The term agile gets used so much that to non-developers it might seem like jargon devoid of any meaning. Developers might know what agile looks like but can struggle to explain it to others (or even themselves). And since no one wants to admit they aren't agile, both non-agile and agile teams claim they are agile lessening the term's value even more.

One definition of agile I hear often is that agile is the opposite of waterfall development. However, to say that agile is the antithesis of planned sequential development doesn't do justice to everything it holds.

According to Martin Fowler, agile software development is "adaptive rather than predictive" and "people-oriented rather than process-oriented." The practice of agile requires teams to have the right technical practices (such as continuous delivery) and discussions instead of detailed requirements. Here is a link to Fowler's Agile Software Guide for more information: https://martinfowler.com/agile.html.

According to Robert "Uncle Bob" Martin, agile teams deliver code every week or every other week, collaborate with stakeholders, and write tests. This definition raises an interesting question whether teams that don't do TDD are agile or not. Here's an interview about the basics of agile with Martin: https://changelog.com/podcast/367.

I myself wrote a blog post series about agile values to reflect more about the meaning of agile. However, I have later found out that the agile principles are much more helpful when it comes to defining agile in practice. While agile values help teams prioritize their activities, agile principles provide actual practices for them.

You can define agile in surprisingly concrete ways. If one way of defining agile classifies you as a non-agile team, it doesn't necessarily mean the particular definition is wrong. It can be that your team isn't, in fact, agile – not every team is.