DEV Community

Mat
Mat

Posted on • Updated on

What agile development actually means

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."

IMO, it's a vague, useless term that shuts down conversation.

But what about real agile?

Forget about methodologies and frameworks. Regardless of how useful these things are, they are not what really 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.

If we're going to pick a meaning of "agile", we should start with the original one from the agile manifesto that proposed the idea in the first place.

The writers of this manifesto came up with 12 principles.

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. [CLASSIFIED]

  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, 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.

Discussion (0)