What do you mean when you say "Agile"?

UPDATE: Added "Agile" as a set of target outcomes.  Suggested by Dale Emery.
UPDATE: Added reference to Agile Manifesto

"I'm glad we all agree what 'Agile' means"

The word “Agile” can trick us into believing that we are talking about the same thing when we are actually not.

Here are a few interpretations that I’ve encountered:

“Agile” as a synonym for good.  Instead of “that would be better”, you’d say “that would be more Agile”. Please don’t do this. This dilutes what is specifically distinct about Agile and discourages thinking. It also leads to tendencies to believe that everything that is not “Agile” (aka good) must therefore be bad.

“Agile” as a particular workflow.  Specifically, backlog -> iteration planning -> in progress -> showcase. In practice there is more variation such as pipelining / “scouting ahead”, more explicit management of specialisation, iteration-less approaches for continuous work situations, etc.

I’ll suggest the essence of an Agile workflow has two basic aspects:

1. Iterative, meaning revisiting and improving based on learning
2. Incremental, meaning large work is broken up into smaller pieces that are delivered independently

“Agile” as a set of practices.  Pair programming, visual workspaces, retrospectives, co-location, involving customers, stand-up meetings, coding standards, showcases, continuous integration, collective code ownership, release and iteration planning, test-driven development, refactoring, evolutionary design, spike solutions, etc. This has the advantage of being concrete… and the disadvantage of implying that every practice is applicable to every context.

“Agile” as an ideal.  Any feature, in any order, one at a time. This requires addressing both fundamental technical and policy constraints and may be incredibly difficult … but provides a clear direction for improvement.

"Agile" as a set of target outcomes.  This is similar to "Agile" as an ideal but using achievable, observable outcomes.  As an example, Elisabeth Hendrickson proposes "Deliver a continuous stream of potentially shippable product increments, at a sustainable pace, while adapting to the changing needs and priorities of their organization".

The potential problem with seeing "Agile" as an ideal or a set of target outcomes is that it does not provide much guidance on approach or method.  That is, the problem of "I'm Agile therefore I should see these outcomes... even though I'm not changing any existing behaviour".

Currently, I prefer the following interpretation:

 “Agile” as doctrine.  By doctrine, I mean a set of fundamental principles that guide actions in support of objectives.  These principles are authoritative but require judgment in application.

This could be "Agile" is "anything that supports the values and principles of the Agile Manifesto" but I would argue that the vagueness of the values and the number of principles typically means that this leads to the "Agile" as a synonym for good problem.

My interpretation of Agile as doctrine is:

1. Reduce the distance between problems and problem-solvers
2. Validate every step
3. Take smaller steps
4. Clean up as you go