When people ask me if I’ve ever done agile research, they say “AGILE” as if it should be capitalized, underlined, and in italics. Their emphasis implies it is something quite new and mysterious. My response is to say I’ve been recommending agile research since long before anyone called it that, then tell them this story:

We advised a client company that had been surveying 1,200 customers once a year to survey 100 customers every month instead. The rewards they reaped from collecting and analyzing fresh data twelve times a year were huge. Investigating each month took into account how our thoughts and feelings change over time as we use products and services more and their strengths and weaknesses are revealed to us (How many times have you been over the moon when your shiny new thing arrived, but the damn thing fell apart a week later?). When situations changed, as they always do, the new monthly surveys picked them up quickly, and decision-makers were able to swiftly formulate response strategies – very agile. Now fueled by a steady stream of data, analysts were able to produce and distribute many useful reports for their constituents. Monthly reports allowed them to spot trends more quickly than waiting around for an annual report. Quarterly reports gave them another way to look at the data, as did Year-To-Date reports, Rolling Twelves, Year-Over-Year, and Annual Reports. We also redesigned the investigations so decision-makers could add topical questions to their monthly surveys and get quick feedback on hot-button issues (very agile). Another benefit of the changes they made was they gathered more and better information – and at half the cost. It is possible to increase quality and reduce costs at the same time, but only under the guidance of people with a gift for such things.

The original concept of agile was connected to the physical world, meaning quick, nimble, and supple. 

The mental version refers to people who are able to think on their feet and adapt to changing situations. The software-writing version was a method that used rapid iterations and implemented changes quickly. You probably know that when writing software programs, programmers don’t write one long program. They write in chunks, with different people given just one piece of an assignment and then assembling the modules later. This method wasn’t merely philosophical, but practical, because early versions are always incredibly buggy. This way of writing software is a faster and cheaper way to be sure, but the downside is that when the chunks are assembled, there will always be bugs because the segments never mesh seamlessly. The results can even be disastrous, as we see when airlines struggle to merge their different legacy systems. 

Sometime after Noah’s Ark, the Holy Bible tells the story of the construction of the Tower of Babel. 

Biblical scholars say the story is an attempt to explain why there are so many different languages in the world when Adam and Eve and the boys started out with only one. According to Genesis, Babylonians wanted to build a tower in their capital city so tall it would reach the heavens. God was annoyed by this, and to prevent its successful completion, cast a spell that made them all speak in different tongues. This made it impossible to understand each other, which made it impossible to coordinate their efforts, so the tower project was abandoned and the people moved away. No one asks why God would be worried anyone could actually build a tower that reached all the way to heaven because at one time, those that did were burned at the stake for heresy. Today, to babble is to utter an excessive, inarticulate, and meaningless confusion of words.

The real roots of agile thinking are in the works of René Descartes.

Still seen today as the gold standard for research when reliable rules are followed exactly, this method will never take what is false to be true or waste efforts unproductively. A mathematician and scientist who devised a universal method of deductive reasoning, Descartes said there were four rules:

1. Never accept anything as true without conclusive evidence.
2. Divide large problems into smaller ones.
3. Solve problems by starting with the simple ones and moving toward the complex.
4. Check and recheck your work often. 

In addition, Descartes insisted that all of the key assumptions and all of the limits of each problem must be clearly defined.

I could not agree more. In my early days as a researcher, I had proudly produced what I believed to be an excellent piece of research only to be told (after the fact, of course) that it wasn’t what sponsors were looking for. It was easy to blame them; their real dissatisfaction was a result of hoping for a fairy tale with a happy ending and getting the facts of life instead. The big realization for me was how I had failed to get all involved to agree on the definitions of what we were looking for before we started, and I vowed it wouldn’t happen again.

The University of Georgia offers these guidelines for breaking down big tasks into smaller ones. 

• Look at the big picture. 
• Identify all the parts of the task. 
• Figure out step-by-step what you need to do.
• Follow a logically-defined sequence.
• Create a timeline for completing your tasks and a deadline for each.
• Allow plenty of time for reviewing.

The British Broadcasting Corporation gives this example of how we solve even very simple tasks by problems into smaller ones. 

Imagine you have hundreds of DVDs and want to organize them alphabetically. Rather than try to sort them all at once, break the task down into sub-tasks like this:

• Sort the DVDs into 26 piles based on the first letter of the title.
• Start with the ‘A’ pile. Organize all the ‘A’s in alphabetical order.
• Repeat for the rest of the alphabet.

By breaking the large task of alphabetizing hundreds of DVDs into individual subgroups, the task is finished more quickly because it is easier to manage.

The Professor and the Madman.

If you read the book or saw the movie, you know The Professor and the Madman is about the making of the Oxford English Dictionary. You learned that the method used by the OED was to assign different time periods to different volunteers and have them follow very specific instructions so it would all fit together later. This technique is still used by lexicographers. A project can be agile without being fast, you know.

So today’s fascination with agile research and agile marketing and agile software development are based upon principles established 400 years ago. The general idea behind agile anything is to change our thinking from doing things in big chunks infrequently to doing things in small pieces much more often. An excellent McKinsey article offers this caution: “Many marketing organizations think they’re working in an agile way because they’ve adopted some agility principles, such as test and learn or reliance on cross-functional teams. But when you look below the surface, you quickly find they’re only partly agile, and they therefore only reap partial benefits. Simply put: if you’re not agile all the way, then you’re not agile.”

Marketers like plug-and-play.

So they often try to buy agile software “solutions” without embracing the philosophy behind them. They like the insider vocabulary, too, and so become fascinated with things like Scrums, Epics, Sprints, Chickens, Pigs, and Burndown Charts. 

Most research buyers ask about agile research with a Yes or No question.

Anyone can easily say yes (kids, did you brush your teeth?), but you learn a great deal more when you ask research sellers to explain themselves to you. Next time you talk with one, ask something like “What sorts of agile research techniques do use and why?”

If you have trouble convincing the boss why doing smaller studies more frequently is so important, ask her why she doesn’t collect and report sales data only once a year?

To read more articles like this, click here.