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.
Thinking about the future & ethnography 
That’s a really interesting parallel you draw, and I’d like to draw another, snarkier one:P
Explorers going native is such an interesting story it’s become a trope. In much the same way people who come to Agile often “Go Native” and become raving fans, sometimes without critical analysis. Now, I know that peer review is a valuable tool for research (ala the agile retrospective), but there’s a danger of those initial insights being horribly, terribly, fundamentally wrong.
Consider cargo-culting, without enough background on *why* a group of natives try to flag down planes, you might consider them to worship them as an avatar of their god, just as they “must have worshipped the great Eagle”, which could lead to a fundamental misunderstanding of their faith precisely because you’re too close to step back (examples may be more contrived then they appear on internet).
People often get “Too close” to agile to see some of its flaws, and users get “too close” to their problems to see how they’re not actually something that software should be doing. Developers do the latter two. So I’m curious to see what kind of quality level for stories you can engineer with a group in both good and bad faith.
Ooooh Dylan what an interesting insight. I have met some of rah-rah Agile cheerleaders you speak of before and you are right there is quite a bit of blindness caused by their affectation for the shininess of Agile. Ethnographers definitely do the same thing. It does pose a true challenge in developing new tool sets that bridge these two worlds since both worlds have a propensity for intensity and for diving very deep into their subject matter. In the creation of tools this will translate to mitigating the two different kinds of risk. The first is using too little or superficial information as gospel and extrapolating far from the original source, which could indicate future meltdowns by having strayed to far from the user’s needs and situation. The second of course is in getting a little too familiar and bogged down in the fanatical empathy loop, which eradicates objectivity and common sense. Maybe the solution could be to develop tools in pairs where the each tool in the pair has checks and balances built in to regulate the other side of the coin.
(When I speak of tools I mean things like workshop techniques, activities conducted with users, interview methods, and data collection and/or collation tools)
Hi Alicia,
About your definition of Agile in the second paragraph of this post: I don’t think many will agree with this definition. Agile is mostly defined as working with as little requirements up-front through small iterations, until satisfaction is achieved.
In any case, I think your post is excellent, and that’s why I would like to republish it on PM Hut ( http://www.pmhut.com) under the Agile category. Please email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.
Sure PM Hut, reblog away, also I have added in your suggestion on an Agile definition that might be more widely accepted.
[…] your blogpost, Agile Ethnography, you explore ways that ethnography can be more agile. I totally agree that applied ethnographic work […]
[…] your blogpost, Agile Ethnography, you explore ways that ethnography can be more agile. I totally agree that applied ethnographic work […]
I am not too sure about your definition of agile and I think the trouble comes from what you mention too – everyone means something different when he talks about agile. What happens is that projects get called agile, don´t work and then “agile” all the sudden made enemies.
Agile IS NOT about the speed of a project, it also does not mean I can change my goal of the project constantly (try and I am promising you it will end in tears 😉 ). It is a way to reduce complexity and it is most of all a way of how a team works together. Take SCRUM as an agile method: you want to make you team work in a way that it manages itself in ideal world. Why? Because the complexity of projects is gigantic, as a project manager who wants to control everything I will go mad. If I understand myself as an enable for the experts in my team I create a perfect environment where experts can manage themselves and work well.
About the goals: a sprint, which is your working rhythm basically, is between 1 to 3 weeks. Imagine every 2 weks someone changes the goal. How do you ever finish something? Where agile helps is that you can tackle problems better along the way and adjust the way how to reach your goal. But if you really establish inbetween a project that you have to change goals, you have a new project. Which is fine too, but again, agile doesn´t mean fast.
What agile also does: it emphasis on the communication between client and project team. Every iteration you present something. In former times (and still nowadays) you would define a highly complex project with your client, he gives you 1 million dollars and a year later you come back with the result. As you can imagine, in many times the client didn`t get what he wanted, because we are all not perfect when it comes to communicate expectations.
So there are things to learn from agile methods just beware of making it quicker with agile. I have seen that ending not well 😉 Thanks for the blog post and your thoughts and I can´t wait to hear what you think about my reply.
I love your points. I feel that so keenly every time we get lured by agile into a sense of calm before the storm. My major point in the post is to say that the unifying theme where ethno and agile communicate could be on a story level. The way that I have seen requirements captured as user stories really sparked my imagination with regards to how complicated or wordy ethnographic communications can be. This phrase from your comment ” emphasis on the communication between client and project team” really resonated. All I wanted to propose is an extension of this communication flow all the way to the customer’s or user’s stories. how can we directly source the customer’s stories using ethnography and inject them to the improving lines of communication that agile provides us a powerful tool to work upon within development? Can users fill out their own user story cards? Can we facilitate this in an ethnographic and non-leading way? How closely can we bring the customer’s into the development by adding an ethnographic methodology into the interfaces between client, developer, and customer?
[…] is this older blog post of mine where I proposed uniting agile & ethnography through their common thread of stories . It has been getting heaps of readers this week. To be very honest the stats kept pinging through […]