What do you mean when you say “Agile”?

Jason Yip
3 min readJun 20, 2016

--

“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”.

“Agile” as the dictionary definition of “agile”. That is, an adjective meaning “able to move quickly and easily”.

In Good Strategy, Bad Strategy, Richard Rumelt says: “Strategy cannot be a useful concept if it is a synonym for success.” The same thing applies to Agile. Agile is a strategy to achieve particular outcomes, arguably only one of which is “agility”. Agile is only meaningful it is possible for it to be wrong or at least inferior to an alternate strategy. I don’t think this happens by equating “Agile” with the dictionary definition of “agile”.

“Agile” as the community. Agile is whatever the current Agile community advocates. The good version of this acknowledges the ongoing learning of skilled Agile practitioners. The bad version of this is when naïve practitioners overwhelm the community and “Agile” becomes mostly a cargo cult.

“Agile” as the industry of consultants, coaches, and certifications aka the Agile Industrial Complex. This is generally the “Agile” people are referring to when they say things like “Agile is dead”.

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

Current examples of this style are Industrial Logic’s Modern Agile and Alistair Cockburn’s Heart of Agile.

My own 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

Currently, I prefer the following interpretation:

“Agile” as strategy

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl