Rewriting the agile manifesto

Published Wed, Jun 6, 2012 by Austin Govella. Updated Wed, Jun 6, 2012.

It irks me when people reference the Agile Manifesto. It doesn't say anything. It's all kittens. It's as if agilistas protest in the streets in support of kittens. Everyone at home watches on the news, nods, and agrees: I like kittens! You like kittens! We all like kittens! KITTENS ARE THE BEST!!!

This rhetorical strategy positions pro-kitten citizens as "good" and anyone who disagrees as "bad". What kind of cold, callous asshole doesn't like kittens? The pro- versus anti-kitten battle distracts us from the real discussion:

  1. Do we want kittens?
  2. Do we need kittens?
  3. Is there anything better than kittens?
  4. Are kittens a good idea right now?
  5. Will any old pet do?

To illustrate this point, I've translated the kittens out of the Agile Manifesto, so we can focus on the real issues at stake:

Manifesto + KittensManifesto - Kittens
Individuals and interactions over processes and toolsReal people doing work over models of people doing work
Working software over comprehensive documentationReal software over models of software
Customer collaboration over contract negotiationReal collaboration over models of collaboration
Responding to change over following a planReal learning over models of learning

When we remove the kittens from the Agile Manifesto, we reveal the conflict between "the real" and "models of the real". We reveal the primary tension between development and design, between disciplines of making and disciplines of modeling. We also reveal the developer's underlying assumption: development is more real than design. But we also reveal the real conversation:

  1. When do we want the real thing instead of a model?
  2. When do we need the real thing instead of a model?
  3. When is the real thing more advantageous than a model?
  4. What are we making? What is the real thing?

These are real questions we can answer for each of our organizations, for each of our projects, for each of the elements of design, and for each iteration. Instead of always assuming the "real" thing is what we want and need, we can evaluate what we're trying to accomplish and whether or not a model would do just as well.