Agile is an Adjective

by sweavo

Below is the transcript of my lightning talk, 99% of which I delivered at Agile Yorkshire 10th December 2013. If you want the full interactive experience, open the prezi and click next each time you read [CLICK] in the text.

What is an adjective?

It describes a thing, e.g.


Tall, Green, Sad.

  • A sad tree
  • The person was very green
  • Our project delivery is quite agile

You can’t “do tall” so why do we nod in polite complicity when someone says they “do agile”?

If I say I’m “doing tall”, what do I mean? Am I growing? Faster than usual? Or am I on stilts? Or wearing a big hat?

What do I mean when I say I’m “doing Agile”? Is it the same things as what my product owner hears? Or the budget holders?

I’m embedded in a team trying to go agile in a wider organisation that is in mid-transition, and is somewhat patchily bought into the concepts. One major preoccupation of mine is communication, especially across the agile / BDUF divide.


For example, a conversation that I had with my product owner:

SM: “Our ability to deliver customer value is hurt by the way priorities change every two weeks”
PO: “But that’s exactly what doing Scrum means I CAN do!”

What’s happening here? Well yes, Scrum does promise this capability, to stop work on features that are no longer valued and switch to reflect emerging priorities, with minimal impact on the delivered product or project timescale. But is doesn’t say that’s the best way to do things!

Looking at our work over the past eighteen months, a common pattern was like this:


as each request came in, it became an epic; then we sliced the smallest possible functional increment in order to have something to demonstrate within a sprint, then at the sprint end the epic would be shelved and a new epic was top priority.

By this pattern of preemption, epics were entering the in-progress state then getting starved of resources, time and again. Customers were getting annoyed at the unbounded lead times.

Meanwhile, we would start getting the bug reports in for the features that we shelved 6 months previously because our focus was switched away after a partial implementation.

So when I opened this conversation with the PO, my observation was that despite the team frequently delivering successful sprints, we weren’t burning up the epics, and the product was still not delivering its potential value in many of its several functional areas, even those that had enjoyed periods of being the most important feature one or more times during the year.

When I suggested to the PO that we should discourage the customer from switching out priorities every sprint, I had in mind that we should increase the emphasis on “focus on finishing” by agreeing to hold the tiller steady until meaningful features were landed. The PO was understandably taken aback, because he valued the ability to switch priorities as laid down in the Scrum documentation for all to see.

What “doing Scrum” meant to me and “doing Scrum” meant to him were quite different.

Developers talk about Code Smell, where certain characteristics of code are not themselves wrong, but they usually indicate that there *is* something that *is* wrong. Like code smell, I think there are also culture smells, and I think use of the expression “doing Agile” is one of them. (Another is writing SCRUM in block capitals, like an acronym.)


Why do we say “doing Agile”? Well, it would be too much of a mouthful to say “I’m doing and promoting and constantly seeking to improve a set of good practices drawn from those accepted by the wider community centred around delivering quality software at frequent intervals and making sure that the outcomes and feedback are communicated effectively to all stakeholders”. So we say we’re “doing agile”. It’s like a macro or a tech-term. Or jargon. Or slang.


Jargon is, let’s face it, one of the fun things about software.  It’s a necessary part of discussing software to come up with new terms for complexes of meaning. For example, in my team we have to be clear whether we are talking about a RunnableEntity, an ExecutableEntity or a SchedulableEntity as each idea carries a set of connotations that have consequences for how the software should work. So we get habituated as engineers to adopting and using new terms or shorthands for ideas.

Slang and secret languages also have a cohesive effect in teams. In my team, everybody knows well what Standard Conversations #0, #10, #14 are, and you can tell the team “Oops that would be me, I checked in a #14 then went to lunch”.  [Meaning, I did something that I thought could not possibly have broken anything and I wasn’t strong-willed enough to do adequate, if any, testing to back up that belief, trusting to fortune that I wouldn’t break trunk. (#10 is “it could catch on” which is used when somebody suggests implementing a unit-test, or reading the spec, and #0 is “#7 is in the wrong tense”)]

But there’s a downside to using this kind of shorthand without checking in that you understand and are understood by the person you are communicating with. In a gelled team, jargon is kept alive by the frequency of communication between the members; the meanings are constantly tested and refined.  Using shorthand terms outside your close tribal group can lead to breakdowns in communication and undermine trust. Even something as seemingly innocuous as to say “doing Agile”.

The problem with a phrase like “doing Agile” is that it wraps up a bunch of ideas in a single term. It puts the idea in a black box. The ideas evoked in the speaker and the listener might not be the same.


Thinking back to my conversation with the PO, perhaps “doing Scrum” means to me:

  • Communication, avoid anchoring, avoid negotiating over estimates
  • Every two weeks we call our own bluff regarding whether the software still works
  • Better contextual information from end users about what is important in the non-functional aspects of the software

Maybe to the PO it means:

  • The team can deliver anything we request within two weeks
  • Planning poker means that backlog estimates are both detailed and accurate

As agile practices gain traction and Agile gains a capital A, we see more and more attempts by command and control organisations to “do Agile”. My employer is one of them. In this organisation, there’s a strong bias towards *execute the procedure* rather than *elaborate the outcome*.


I expect many large organisations are biased this way. Waterfall is a recipe of actions which, if you execute them — and take your eye off the outcome — you end up building the wrong thing… and if only you executed the actions more carefully, with more focus, then you might get the right thing. These cultures see “Agile” and read that it deals with the problems of risk and expense and budget overruns, so they want it. But on a fundamental level, they still view Agile as a recipe of actions. That is why they prefer to “do scrum” than to “try to become more agile”. They also still expect to take their eyes off the outcome and get the right thing. Managers got a quieter life throughout the old project lifecycles. Iterative delivery creates pain by eventuating risks, and managers need to unlearn that shouting at underlings until they keep quiet about problems is the most effective way of removing the pain.

What has this all to do with Grammar?

If agile is a noun, like a tax return, or waterfall, then as soon as you *do* it, you expect to check it off. We are doing iterations, so why don’t you have these great features every two weeks? We locked the team in a warehouse across town [away from PO and the testers] and told them to do Scrum for 6 months, and they still delivered something not suitable for deployment. But we’re doing Scrum!

If agile is an adjective, a quality of something, then it can’t be dismissed so easily. You have to unpack it to understand what is meant. The question “Is the team agile?” is so patently meaningless by itself that you are compelled to get a clarification. Do you mean are our iterations regular? Do we succeed most sprints? Are we able to respond to customer feedback in an acceptably timely way? Already the attention is on the outcomes of agile practices, in terms of the capability profile of the development team.

Rather than being content to “do scrum”, ask yourself and your stakeholders what you wish to get out of the team’s agile practices. What capabilities you value in your software development engine. Keep a mental Jenkins server that turns red when they are violated. If the PO likes “turn on a dime from one sprint to the next” then asks for a feature that will take a full sprint just to understand the question and rough out a demo, then this can be flagged and the trade-off understood.

If you treat the development team as the product, then these kind of capabilities are its features. The capacity of the team to act or react in particular ways or to produce a particular quality of work are outcomes for the process of reflection and improvement. This is where the (meta) value is, not in “doing agile”.

In short, come back to outcomes, not activities.

Ok, SAY I buy all this. How do I stop saying “doing agile?” it’s such a useful phrase!

I’m glad you asked me that. You only need to enforce one simple rule to improve your spoken precision:

Make sure you follow “agile” with a noun: ask yourself “agile WHAT?” before you speak.


  • We are adopting agile practices
  • We follow the agile manifesto
  • We try to use agile estimation

This makes you think harder about what facet of software development you are actually talking about at that moment.

And remember:


Outcomes beat activities.
Declarative beats imperative
Adjectives beat verbs and nouns.


Agile is an adjective.