I try and avoid the word "agile" as much as possible. It gets used too much as a buzzword (by consulting companies and tech leaders) or as a euphemism for "whatever we're currently doing, but faster."
At best, it's a vague, useless term, and at worst it can shut down valuable conversations.
Agile Methodologies != Agile
People talk about agile methodologies and frameworks - SCRUM, Kanban etc. But regardless of how useful these things are, they are not really the thing that distinguishes "agile" from "non-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 (providing 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 good stuff behind agile
If we're going to pick a meaning of "agile", we could do worse than look at the agile manifesto, which proposed the idea in the first place.
The writers of this manifesto came up with 12 principles.
The agile principles
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
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. (IMO, this one is less important now we have better tools for remote working)
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
The agile principles stand on their own
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 is still relevant
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.
Ron Jeffries said in 2010 that the agile manifesto states an ideal, and the industry has fallen short of it. I agree - 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.
Top comments (0)