Experiments = Experience + Insight

We who work in innovation, transformation, change, and all the capital letter functions trying to make the world a better place for you and for me,

It has been a weird journey to understand the cultures around the greater market of ‘I’nnovation. Capital ‘I’ Fancy stuff, that is. Whole world is full of us, it is. You’re probably familiar with how innovation works in your own world already, you are. Likely this post will bore you, it will.

Anyways here goes my attempt at sense making based on all the social media conversations, articles, and interactions I have been able to participate in in my short time in innovation spaces:

Who isn’t innovating these days?

Who isn’t venturing or starting up?

Who isn’t trying to sprint, lean, agile, iterate, synergise, partner and ally?

Who isn’t platformifying?

We’re inundated with these words that we’re using so much they are quickly going to be meaningless for us all. (If they aren’t already in our ‘cliche’ box).

The question for all of us is: Who is experimenting?

It is from experimentation that the seeds of innovation grow. It is the brave  and lucky who we hold up as innovation heroes. Those who were courageous enough to increase their risk radar to experiment and then kept at it long enough and got lucky to produce value. Those folks are our innovation heroes. There is your Tesla, your Musk, your Edison. They had a process and for some of them it was called the scientific method, a rigorous framework for experimentation.

How can we innovate without experimentation? Can we call it an innovation if someone happens upon a perfectly tailored and commercialisable solution by coincidence the first time? First of all it is doubtful that will happen. Research and development departments, university research labs, most of science, and some of design have all put forward their own specific ways of experimenting. We’ve been experimenting forever in kitchens, in cobbler’s shops, in the fields, over hills, and in the dales. Yet somewhere along the way some folk out there have flogged the experimentation out of the innovation. Too constrained in their risk approach to even approach a true experiment. Always wanting to know the R.O.I. (return on investment) before the first line of the story has been written. We get stuck in a loop of business cases to run experiments to build better business cases. (p.s. nothing against business cases, they are super useful). How will we ever run fast enough and iterate enough in order to innovate enough to save ourselves, our species, our planet?

Here comes agile to the rescue, and its good friends lean start-up, 5 day sprint, special intraperneurship, design thinking, idea battles, concept development carousels, and a whole host of ways to speed up and discount the costs and risks of innovation. So if we make it small enough and palatable enough the experiment will gather support and the snowball will begin its momentous roll uphill or downhill. In this world no matter where you sit it is a matter of storytelling and some charisma to get your experiments off the ground. Sounds pretty full of bias that decision making process does, better build a  solid ROI and business case for your experiment, you might. The little business suit wearing calculator in your head might now be thinking, “Gee don’t know how you plan to run a profitable business while throwing all that cash at your so called ‘experiments’.”  Well that’s the deal kids! Most experimental and innovative places don’t turn a profit…for a really long time! Start-up business models have only in very recent history provided us with the stories of instantaneous IPO payout glory.

It is not an experiment if you know the outcome.

If you know the outcome you can call it all sorts of things but not an experiment.

How do we in the face of so much activity in the name of ‘I’nnovation sort the wheat from the chaf? How can we define a real experiment? More importantly how can we bulldoze the space to run true experiments and not just evaluative confirmatory studies?

Teach your bulldozers what they need to know to be the best possible bulldozers they can be. Your bosses, their bosses, their bosses, and onward all need to be empowered with a clear narrative of what you want to learn from your experiment. Learning is valuable, and people pay for learning and information. All we need to do as experimenters is be able to tell the value story of the knowledge we are pursuing. What do we want to know? and why will this experiment help us know more than we did before? How can that knowledge help us make better decisions and help us allocate what we’ve got now better in the pursuit of what we want tomorrow?

Abstract hack of an experimental process

Completed prior to the experiment

1.Title of experiment: Make it meaningful and descriptive

2.Purpose: What do we want to know when we’ve done this – 1 or 2 lines to describe the objective of the experiment, or your focal question (Customer, client, & stakeholder ecosystem & needs)

3.Materials: list of all the inputs required

4.Procedure: the steps and plan that will be enacted to run the experiment, including the exact data collection plan (& dates if you can include them)

Completed during and after the experiment is run

5.Data collection: observations, data points, &  readings from instruments

6.Data analysis: method and findings of analysed data

7.Discussion of learnings: synthesis and meaning making out of analysed data

8.Design recommendations for next experiment: ideation, preparations, & planning of next experiment

Then once you’ve conducted the experiment,

SHOW YOUR WORK! SHARE YOUR WORK!

If you don’t share your learnings what are we fighting for?

 

Do you have any better experimental frameworks you can share with me?

Let us go forth and know not what our outcomes might be but focus instead on each step of our journey.

 

 

Play nice: design ethnographer meets management consultant, an interview with Alicia Dudek from Deloitte Digital

Play nice: design ethnographer meets management consultant, an interview with Alicia Dudek from Deloitte Digital.

I met Trisha Wang at EPIC 2013 last year and our discussion turned into an interview which has been put up on Ethnomatters, one of the the premier ethnographic community blogs.

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.

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.