When I speak at Agile conferences, I often open with a couple of questions to the audience:

“Who here follows an Agile or Agile-ish software development method?”

Startups collaboration meeting business

Depending on the audience, I usually get around a quarter or half of the group nervously raising their hands, wondering what is going to come next. My next question is:

“What is Agile?”

Invariably there is an awkward silence at this point and the occasional giggle. After ten or twenty seconds a hand usually goes up and possible answers are suggested:

  • A way to incrementally deliver software
  • A quality-based approach to software development
  • Scrum
  • The Agile Manifesto
  • Responding to change
  • An excuse for cowboy coding

All of these are interesting answers and lots of other answers have been suggested to me over the years, and I think that this illustrates the point nicely:


Nor do I think that they should. The diversity of ideas and friction between those ideas stimulates innovation in software development. It is fascinating to see how ideas, tool and techniques that have been so successful for one team, fail to have an impact on another team.

Different Methods

An array of different Agile methods (I refuse to use the term methodology) exist and they are all different. Each method was developed by an individual or group with a specific situation in mind at a specific time. The method as presented in your Scrum book, DSDM book, Extreme Programming book etc is unlikely to be the best method for your individual team and situation. These methods are a fine starting point for a team, but they are not the destination. Each of the popular approaches to Agile acknowledges this idea that no one size fits all. This idea is embedded into the process, usually in the form of a Retrospective.


A Retrospective is a team meeting at the end of each Sprint (AKA iteration AKA timebox) at which the team considers what went well and what went badly. The purpose of the Retrospective is to MAKE CHANGES TO THE DEVELOPMENT PROCESS in order to improve things. In this way, Agile is a self-modifying process driven by a never-ending quest for perfection.

Many of the teams I teach and coach who claim to be doing Agile do not run Retrospectives or any equivalent process and so they are simply slavishly half-following a process laid out in a book that they read or a course that they took. These teams have no concept of continuous improvement and are destined for a slow decline into low morale and low productivity.


The impact of implementing small, regular changes as a result of retrospectives is profound. Development teams should be able to look back after a year of retrospectives and realise that somehow their core development process has become radically different over the preceding twelve months. The radical change comes about as a series of small, evolutionary changes rather than as part of a single big bang.

What Is Agile?

So when I am asked “What Is Agile?”, my current answer is:

“A relentless, never-ending quest for improving software development”

I will adapt to changing circumstances and adopt ideas from any method and any discipline in order to improve my development process.