Agile Ethnography: A proposition

In the midst of yet another awesome agile project I turn my thoughts to the idea of Agile Ethnography. It could be amazing. You could have the best of both worlds.
In the midst of yet another awesome agile project I turn my thoughts to the idea of Agile Ethnography. It could be amazing. You could have the best of both worlds.

Ethnography is a rather labour intensive study of people in their contexts. It grew out of a very rigorous academic world filled with armchair anthropologists and explorer’s gone native on pretty Pacific isles. Like the second half of the word suggests ethnography, was all about the -graphy. Writing (lots of it) is the fundamental communication tool that was used to describe the findings in the field and to chronicle the emotional response and observational bias that came from the researcher being self aware of the impact his or her presence was inflicting upon the research. To put it succinctly ethnography is traditionally a self conscious, in-depth, laborious, time-consuming, exercise whose major benefit is in uncovering the deep motivations and patterns of specific people in specific contexts. Oh lawd almighty, it is so fantastic, you have no idea how thrilling it is until you are out there in the field having insight after insight come pouring into your notebook.

Now a bit about Agile. It is a methodology to run a project in a manner that is supposed to be all about focusing on working on the most highly prioritised requirements of a project first in order to come out with a minimum viable product first and work on refinements and additional features in further iterations. PM Hut kindly pointed out that a common definition of agile varies slightly from my own experience, ” Agile is mostly defined as working with as little requirements up-front through small iterations, until satisfaction is achieved.” In my experience with Agile, and I am certainly no pro, everybody has their own way of defining and doing Agile so there are as many perceptions of Agile out there as there are projects.  There are all sorts of ways that Agile projects are run using things like scrums, stand-ups, story cards, epics, story points, and many more. I won’t bore you with explaining them, I know you can Google like a boss. The moral of this story is that Agile is all about being lean, moving quickly, and iterating. In an ideal situation Agile is a no waste methodology where your efforts are directed to only the most promising candidates in your to-do list (a.k.a. backlog).

So how do we reconcile a labour intensive and detail oriented science like ethnography, which focuses on holistic contextual understanding of people in a situation, with something like Agile, which a structured approach to quick and dirty development with shiny results? Well from where I stand there are actually a lot of similarities. In ethnography you follow your nose and go where the leads take you. Agile and ethnography can jam on that harmony, but wait there is more! Agile and ethnography have a heart string in common, the all powerful story. Ethnography at its core is about telling the story of a people in a compelling manner to draw out the insights that highlight new knowledge about the people and their context. Agile is centred on developing requirements in a very specific story format: As a (fill in the description of the user), I want to be able to (fill in the description of the function), so that (fill in the description of the motivation/reason). Somewhere in this deeply story-centric core of Agile and Ethnography lies the opportunity to expand and extrapolate new methods that can create synergies between the two to benefit both schools of thought.

In my case I am really interested in making design ethnography tools for the Agile managed project. These are user experience research tools that help you flow the ethnographic quality of user stories straight into the requirements of the Agile methods. I want to be able to eliminate the double-handling, the constant collation of data, the endless transcription. Who says we can’t just ask users to write their own stories? who says we can’t interact with our participants on the same level and with as much transparency as possible? Who says we can’t remove the obstacles and just get on with the art of getting the stories of real people incorporated directly into the things we build for them? Isn’t that why people do design ethnography or user experience research? That’s why I do it, and I am going to find more fun, interactive, and direct ways to have the participants participate.

Nowadays what project isn’t Agile?

Seriously, everything is Agile it seems, and a lot of it is simply called ‘design thinking.’  One reason could be that you have to work in the Agile manner in order to compete in constantly disrupted markets. Beyond that, it might be the oldest artifact of design thinking turned business process. According to the all powerful wiki, Agile started sprouting in 1957. (Don’t know what Agile is? I wiki-ed it for you  here )

Furthermore working agile-style applies to many domains, not simply software or web development. It helps eliminate the expensive downtime of people with super specialized skill sets sitting and waiting for “their turn,” something that is bound to increasingly occur as complexity envelopes us. You might not think about it often, but the things we use and depend on everyday are the products of A LOT of highly specialized skilled people. A company generally wants to profit somewhat from the products it makes, and hence working un-Agile-ly is simply a high cost and high risk maneuver, considering the state of economies and market competition.

I personally like it because its so personable and has a veneer of Buddhist thought to it. I am an iteration junkie, maybe that grew out of obsessive compulsiveness and perfectionism, but in an iterative cycle you can always go back and fix a little, just straighten it up you know what I mean?

Another reason I might be a fan of Agile is that I am a firm believer in the awesome Dwight D. Eisenhower’s idea that,  “Plans are nothing, Planning is everything.” How many times does the wrench get thrown in the works? Followed by the whole toolbox’s worth of knots and kinks, which is an apt analogy because so often your own tools are what complicates and works against you during a project. I think I’ll lead the Agile life, it’s all just an iteration you know?


Agile, it's just so bendy and zen how could you not love it?