There’s a lot of talk about Agile these days. Agile Development, Agile Business, Agile Marketing, and, yes, Agile Research.
They typically have in common a set of fundamental principles, usually expressed as a manifesto, that challenge conventional thinking and promise to disrupt standard procedures and business methods. Most are provocative. Many laudable. The kinds of statements of intent and expressions of goals that only the hardest of the hard-core status quo protectors would reject.
Unfortunately, as well, they also come with their own jargon. It’s as if we can’t help ourselves. Like nature abhorring a vacuum, business abhors simplicity.
Scrums, sprints, spikes, timeboxing, scrum-masters, burndowns. One or two steps away from their original definitions, they become needless abstractions. Even some very provocative notions—just-in-time delivery, test-driven development, continuous integration—get abbreviated into meaningless acronyms. JIT. TDD. CI. JBGE. ALM. XP.
Really?
When did Agile stop being, well, agile?
It seems to us there might be a good rule of thumb here: if your strategy requires its own glossary, it’s probably gotten overly complex. You’ve simply swapped out one set of acronyms for another.
For the sake of everyone—the clients we serve, the product we develop, the people we do business with—let’s promise to adhere to some very basic, jargon-free precepts. Simplicity. Clarity. Directness. Openness.
Otherwise, Agile will simply be DOA.
Agile Research 