Everyone’s “agile”

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 subjectivity¹. 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 way² 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.³ 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.⁴

I hear Relevance is hiring.

:F