I try and avoid the word "agile" in my work. It tends to be used as a shorthand for all sorts of things...
...from "we're agile, we definitely know what we're talking about!"
...to "I just want results now!"
...to "we promise that we are not basing our software development process on a flawed model from the 1970s"
IMO, it's a vague, useless term that shuts down conversation.
If we are going to pick a meaning of "agile", we should go with the original one from the agile manifesto.
I don't think methodologies like Scrum should be conflated with the idea of "agile". They are just a way to organise teams that come with some "agile" baked in. Kind of like how Ruby on Rails isn't the same as "a decent web app", but having a framework can make it a lot easier to get started, if you know what you're doing.
Just like developers can still build shitty rails apps, managers can implement half-arsed agile without really embracing the mindset.
The writers of the agile manifesto came up with 12 principles that should guide software development.
Here's a list of them:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Welcome changing requirements, even late in development
Deliver working software frequently
Business people and developers must work together daily throughout the project
Give team members the environment and support they need, and trust them to get the job done
Working software is the primary measure of progress
The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Each of these principles is clear and objective.
As a team you should be able to reflect on any of them and ask "are we really doing this?"
If you really value early and continuous delivery of valuable software, you should expect to be prioritising work based on value to the customer. If not, then why not? This is a far more interesting and productive conversation than simply "are we agile enough?"
If you value delivering working software frequently, alarm bells should be ringing if there are long delays between writing and testing code, or if deploying code to production is too scary to do every day.
If you value simplicity, you should be able to challenge scope creep. If you value technical excellence, then you should have things like code review, tests, linters etc. which enforce a standard.
If working software is really the primary measure of progress, you should spend time measuring how well your software is actually working for the people that use it! If the things you measure and reward just relate to inputs, like velocity, tickets completed, or lines of code written, then you probably don't value working software as much as you think.
This was written in 2001, but for the most part it's still very relevant today.
Compare that to the Joel Test, a list of development practices written in 2000 as a way of rating the quality of development teams. It's laughably out of date now.
I agree with Ron Jeffries, who in 2010 said that the agile manifesto states an ideal, and the industry has fallen short of it. We should be able to do better.
Ultimately, it doesn't matter what you call things, you can implement any of this advice to your own team with or without calling it "agile", and doing some of these things is still better than doing none of it.