or learn more

Everyone’s “agile”

Aug 3, 2012

Everyone’s agile

Last Monday I recorded an interview with Craig Andera for the Think Relevance podcast. You’re likely to hear it some time soon, but I wanted to mention at least one point made during the discussion in more depth. As some of you may know, I recently left Relevance, but my feelings for the company and its employees (family?) run deep. Of the many lessons learned while on the job, one in particular that literally struck me dumb was a lesson in “Agile software development”; that I will attempt to describe the best that I can herein. The premise starts with the observation that the term “Agile” has experienced a mutation in the past decade (give or take).

Stop the presses, a term associated with the software industry has changed its definition over time!

Nothing new here right? However, unlike the transmogrification of the precise definitions for technical notions like “closure” or “object-oriented programming”, the definition of “agile” has always had an air of subjectivity1. The very charter of the Agile movement, the Agile Manifesto, while important as a driving force, has subjectivity baked into it by design. That is, I believe that one of the key aspects of “Agile” is that every project is different and no amount of static planning (e.g. ponderous requirements documents) will guarantee success. Instead, success is more likely to occur in the presence of team and customer collaboration at every step of the project. Working in this way2 is more likely to identify problems or shortcomings and dealing with them in a mutually agreeable way (hopefully) quickly and efficiently.

This sounds great! The problem arises, as it does in any system built on (and in fact, requiring) subjectivity, in that everyone already thinks that they adhere to the system. That is, if you take a historically stodgy, ponderous company and suddenly institute a stricture of daily 15 minute standups, suddenly everyone thinks they’re being agile! Suddenly job listings from said company list “Agile methodologies”, Scrum, lean this and lean that.

Stop the presses, companies in the computing industry have usurped a word for their own purposes!

Nothing new here right? The problem however is that when something like this happens you have guys like me who dismiss everything with “Agile” out of hand. This is exactly what I did before I worked with a company that was actually agile

You see, what makes a company actually agile is not only a willingness to address project-level inefficiencies and roadblocks as they occur, but also a fervent desire to do the same at the meta-level.

Well, what the heck does that mean?

The difference, as I see it, between Big Honking Software Company that institutes daily standups and calls themselves “Agile” and an actually agile company is that the latter agonizes over introspecting and retrospecting about the very agile processes put into place.

Whereas Big Company will strictly institute agile processes, an actually agile company will periodically reassess if the very agile methodologies themselves are appropriate for any given project or customer.3 While Big Company is interested (and always interested) in building institutions of methodology, Relevance is willing to tear down the very methodologies that define them if the need arises.

This was an amazing thing to see and something that will take me some time to fully come to terms with. If you’re interested in observing actually agile, then seek a company that is unafraid to introspect and retrospect.4

I hear Relevance is hiring.


  1. You can say the same about OOP, but seriously, read the opening volley on the Wikipedia page defining Agile — it could mean almost anything. 

  2. That’s not to say that you should forget about thinking. Agile does nothing if both you and the client have no idea what you’re supposed to create. This is not news right? 

  3. Agile is to be agile in the face of non-agile clients. 

  4. I didn’t even discuss the fact that during my time I saw an unbelievable number of high-quality systems built under seemingly impossible time-lines… all in 40 hours a week. If that’s not agile, then I don’t know what is. 

2 Comments, Comment or Ping

  1. configurator

    I’ve only worked in one agile company, and it was actually agile. We considered whether we need a card wall for every single project. And did the same for sprint planning, daily meetings, etc.

    One of my projects had the client on video chat once a week to plan what we do that week; another one was pretty much laid out from the start because we had all the requirements and there wasn’t anyone who had any authority to change anything major – or even cared enough to – on the client’s side. One extra-fun project wasn’t agile at all, but had a moving target that we kept doing our best to aim at (and was a major success because we had a great team).

    That was a good company to work for.

  2. Yup, the term “Agile” is subjective, but I think it should be possible (albeit very difficult) to systematize many “Agile” traits. (Anything is possible) :-)

Reply to “Everyone’s “agile””