Please stop saying agile all the time
Tags: agile, teams, people
Published: 2020-11-10 13:34:59

---
title: Please stop saying agile all the time
published: true
description: The word agile has become a buzzword, but the original principles are still relevant and valid
tags: agile, teams, people
//cover_image: https://direct_url_to_image.jpg
---
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](https://www.halfarsedagilemanifesto.org/) 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](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/).

## The agile principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2. Welcome changing requirements, even late in development

3. Deliver working software frequently

4. Business people and developers must work together daily throughout the project

5. Give team members the environment and support they need, and trust them to get the job done

6. 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*)

7. Working software is the primary measure of progress

8. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

9. Continuous attention to technical excellence and good design enhances agility

10. Simplicity–the art of maximizing the amount of work not done–is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. 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](https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/), 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](https://ronjeffries.com/xprog/articles/beyond-agile-new-principles/). 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.