Our first application of Agile principles to the research process, which occurred during our study of thought leadership in the tech industry, was a very Agile-esque journey into the unknown. We learned a great deal that applies to future applications of Agile Research Development, so here's my retrospective.

You Can Be Agile Up To The Boundaries Of What You Control
Ultimately, you control only part of the value stream. This maxim holds true wherever you apply Agile, and software developers learn this principle right away. You can be the most disciplined developer imaginable, never checking in code that doesn't work, always building in tests, and still be at the mercy of your own QA team. And even if the larger team, including testers, works in blissful harmony, someone needs to deploy the code on a live system. (Which is why dev ops is receiving a lot of attention from within the Agile community these days. See Jez Humble's recent book for a good example.)

If a stream is an appropriate metaphor for value creation and delivery, then this stream always takes many twists and turns, frequently encountering dams and obstructions. The success of Agile, therefore, depends to a great extent on eliminating these kinks, navigating around them, or learning to accept them as part of the value stream's trajectory. 

As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.

Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)

"Follow The Money"

We're now in Phase II of our first venture into Agile Research Development, an investigation of thought leadership in the technology industry. Phase II is when we start the actual primary research, and again, we're looking to the community for their help and guidance. The story so far:

• Published the development document, which explains how we'll proceed. Supporting documents, such as this overview of Agile Research Development, are also part of the project dossier.
• Incorporated feedback from the community into the development document. Many thanks to everyone who provided suggestions and criticisms of the original research plan, as described in the development document. In fact, if you haven't read the comments on the development document, I strongly recommend that you do. There are some real nuggets in there about a thought leadership, a topic of vital importance to tech vendors, their partners, and their customers.
• Drafted the interview guide. We now have a list of questions that we'll ask the interviewees, including both vendors and customers.

How You Can Help
First, we need another round of review. This time, we're looking for your feedback on the interview guide. Are these the questions you want answered? Have we missed anything? I've annotated the interview guide to explain some of the reasoning behind the current draft, which is my way of getting the discussion going.